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ABSTRACT 

Successful  development  and  evolution  of  the  Defence  Information  Environment 
requires  the  organisation  to  develop  an  architectural  culture  in  its  Information 
Technology  (IT)  practice  and  future  organisation  development.  In  such  a  culture, 
the  organisation  must  achieve  an  integrated  architecture  capability  for  high-level 
knowledge  creation,  management  and  reuse  within  its  improved  IT  development 
capability.  This  report  discusses  the  main  issues  facing  the  organisation  in 
developing  such  an  integrated  architecture  capability,  and  proposes  employing 
architecture  practice  concepts  at  the  level  above  individual  architecture 
development.  High-level  management  and  integration  solutions  associated  with 
architecture  practice,  and  responsibilities  of  relevant  parties  are  also  discussed  in 
the  report  to  help  reach  a  shared  understanding  of  the  practice  required  by  the 
ADO.  The  report  aims  to  provide  a  basis  or  context  for  the  Architecture  Review 
Board  to  plan  and  organise  the  architecture  practice  and  to  produce  more 
detailed  guidelines. 
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A  Framework  Study  for 
Australian  Defence  Organisation  (ADO) 
Architecture  Practice 

Phase  1  -  Client  Report  (Part  2) 
Architecture  Practice  Study 

Executive  Summary 


According  to  the  Defence  Information  Environment  (DIE)  Strategic  Plan,  development 
of  architecture  practice  for  the  Australian  Defence  Organisation  (ADO)  is  one  of  the 
three  main  activities  associated  with  developing  an  architectural  approach  for 
successful  development  of  the  Defence  Information  Environment.  Such  an  architecture 
practice  is  an  agreed  method  to  guide,  plan,  formulate,  review,  manage,  coordinate, 
maintain,  publish  and  use  architectures  throughout  the  defence  community. 
Investigating  rational  and  practical  solutions  for  successfully  developing  ADO 
architecture  practice  has  been  the  main  focus  of  the  Architecture  Practice  Study  task 
DSTO  (JNT99/017).  This  report  is  Part  2  of  the  Phase  1  Client  Report  of  the  task. 

This  study  discusses  architecture  issues  in  the  context  of  the  whole  ADO,  and  in 
particular  issues  relating  to  C4ISR  systems.  Architecture  is  considered  in  a  broad 
context  as  knowledge  about  a  system,  with  this  knowledge  being  described  and 
represented  by  a  set  of  views  that  together  reflect  the  concerns  and  requirements  of  the 
stakeholders  of  the  system.  In  discussing  these  issues  the  three  critical  roles  of 
architecture  are  illustrated,  with  these  being:  a  picture  of  the  current  state;  a  blueprint 
or  vision  for  the  future;  and  a  roadmap  as  guidance  on  how  to  get  there. 

Based  on  the  context  analysis  and  principles  study  of  architecture  practice  presented  in 
Part  1  of  the  Phase  1  Client  Report,  this  report  presents  a  framework  study  for  ADO 
architecture  practice.  Through  briefly  reviewing  the  history  of  ADO  architecture 
practice,  and  the  experience  and  achievements  of  the  US  DoD  in  architecture  practice, 
the  report  initially  presents  a  background  study.  The  investigation  into  the 
requirements  of  architecture  practice  for  the  ADO  reveals  that  the  ADO  architecture 
practice  should  target  the  improvement  of  ADO's  Information  Technology  (IT) 
development  capability  or  future  organisation  development  capability  as  the  main 
objective,  since  any  use  of  architecture  is  part  of  implementing  this  capability. 

The  use  of  architecture  is  not  limited  to  system  design  and  development.  It  can  also  be 
used  as  a  way  to  bring  together  the  various  stages  of  capability  development  and 
support.  A  working  paradigm  is  presented  that  shows  the  relationship  between 
architecture  knowledge  and  the  four  aspects  in  the  cycle  of  capability  development  and 
support.  These  four  aspects  are:  research  and  development  for  future  capability; 
enterprise  planning  and  business  description;  system  development  and  general  IT 
guidance;  and  system  management  and  maintenance. 
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In  fulfilling  its  roles  across  the  various  aspects  of  capability  development  and  support, 
architecture  can  be  seen  as  having  six  main  attributes  determining  its  context  in 
multiple  dimensions.  These  attributes  are:  object/system  associated;  role  (of  the 
architecture);  view  type;  time  ("as-is"  or  "to-be");  methodology  used;  and  tool  used. 
Without  clear  specifications  on  these  attributes,  the  value  of  a  specific  architecture  can 
not  be  clearly  presented.  It  is  these  inherent  attributes  that  create  complicated 
relationships  amongst  various  architecture  views  or  products. 

In  order  to  successfully  support  the  Defence  Information  Environment,  the  ADO 
requires  an  integrated  architecture  capability  that  can  successfully  evolve  over  time 
and  become  part  of  the  organisational  culture.  While  developing  individual 
architecture  products  does  provide  a  limited  capability,  the  integrated  development  of 
architecture  is  required  to  satisfy  the  broad  needs  of  the  ADO.  The  aim  should  be  to 
develop  a  mature  architecture  culture  in  which  any  architecture  is  developed  in  a  well- 
defined  context,  at  the  right  time,  using  an  appropriate  methodology,  and  is  one  that 
can  be  integrated  with  others  and  used  widely  and  effectively. 

Using  a  high-level  conceptual  model  of  the  IT  development  capability  required  by  the 
ADO,  the  study  identifies  the  main  architecture-based  capabilities  that  can  support 
different  aspects  of  the  IT  development  capability.  These  include  various  descriptive 
and  supporting  architecture  products,  architecture  repositories,  advanced  architecture- 
based  systems  planning,  modelling,  simulation  and  measurement  of  performance.  An 
integrated  architecture  capability  is  believed  necessary  and  important  for 
improvement  of  future  organisation  development  capability. 

Through  applying  the  principles  that  a  disciplined  architecture  practice  should  use  as 
proposed  in  Part  1  of  the  Client  Report,  the  report  discusses  the  main  interests  and 
responsibilities  of  the  Chief  Information  Architect  and  the  DIE  Architecture  Office 
(DIEAO).  Also  discussed  is  the  proposal  that  architecture  practice  concepts  at  the  level 
above  individual  architecture  development  should  be  adopted.  Based  on  such 
thinking,  three  main  views  of  managing  architecture  practice  architecture  product 
view,  process/methodology  view  and  tool/environment  view— are  discussed  with 
certain  methods  and  solutions.  The  main  challenges  in  ADO  architecture  practice  are 
how  to  clarify  the  value  of  each  architecture  and  fully  realise  it  in  practice. 

Success  in  architecture  for  the  ADO  will  rely  on  the  well-organised  community  practice 
in  which  the  core  business  is  not  only  production,  but  also  more  importantly  sharing, 
management,  evolution  and  reuse  of  organisation  business  knowledge  and  systems 
and  IT  knowledge  through  using  the  concept  of  architecture. 
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1.  Introduction 


The  importance  of  and  reliance  on  information  systems  architectures  has  grown 
steadily  over  the  last  decade  as  computer-based  systems  throughout  the  Australian 
Defence  Organisation  (ADO)  have  become  larger,  more  complex  and  more 
interconnected.  Apart  from  coping  with  the  common  set  of  symptoms  in  IT  practice 
mentioned  in  Section  1  of  Part  1,  the  ADO  is  now  facing  greater  challenges  in  seeking 
solutions  for  implementing  new  technologies  in  response  to  the  changing  needs  of  the 
business.  Acquisition  of  systems  of  systems  will  further  increase  the  magnitude  of 
complexity  that  will  have  to  be  managed  if  the  systems  of  systems  concept  is  to  become 
a  reality. 

Australia's  Strategic  Policy,  1997  assigns  the  highest  capability  development  priority  to 
achieving  the  Knowledge  Edge.  Developing  the  Defence  Information  Environment  (DIE) 
is  seen  as  one  of  the  key  tasks  required  to  realise  the  knowledge  edge.  In  order  to  be 
able  to  successfully  carry  out  such  a  task,  the  ADO  needs  to  first  examine  what  kind  of 
development  capability  is  required,  and  whether  the  existing  capability  is  ready  to 
deliver  what  is  expected  for  the  DIE.  The  quality  level  and  success  of  the  DIE  is  largely 
determined  by  the  level  of  this  development  capability,  which  should  be  much  more 
comprehensive  than  that  used  for  a  single  project  or  individual  system  development. 

The  historical  experience  and  current  situation  of  IT  practice  in  the  Department  shows 
that  improvement  of  IT  practice  or  IT  Development  Capability  (ITDC)  is  a  challenging 
issue  that  is  waiting  for  better  solutions.  Without  significant  improvement  of  the 
ADO’s  IT  development  capability,  the  DIE  development  will  face  significant 
uncertainty. 

Architecture  Practice  is  an  emerging  discipline  that  is  aimed  at  systematically 
addressing  principles  of  generation,  management,  evolution,  use  and  reuse  of 
architecture  in  the  context  of  evolutionary  development  of  systems  of  systems  within  a 
large  organisation.  Introducing  such  a  discipline  within  an  organisation  is  seen  as  a 
culture  change  or  culture  development  that  can  gradually  facilitate  architecture 
capability  developing  and  becoming  an  effective  organisational  capability. 

Part  1  of  this  report  addresses  the  main  issues  of  architecture  practice  in  general  for 
large  organisations,  including  definitions  of  architecture,  confusion  and  complexity  in 
architecture,  comparison  of  architecture  frameworks  or  approaches,  and  maturity  level 
of  architecture  practice.  An  Architecture  Knowledge  Value  Chain  based  Architecture 
Practice  Conceptual  Model  for  large  organisations  is  discussed  in  Part  1.  This  model 
can  be  used  as  a  basis  to  either  examine  coverage  of  existing  architecture  frameworks, 
or  to  plan  and  manage  at  a  high  level  architecture  practice  for  a  large  organisation. 

This  part  of  the  report  will  study  specifically  the  context  of  the  ADO's  architecture 
practice,  including  history,  achievements,  current  situation  and  comparison  with 
architecture  practice  of  US  DoD.  The  main  objectives  of  the  study  are  to  assist  the 
Defence  Information  Environment  Board  (DIEB)  and  the  Architecture  Review  Board 
(ARB)  in: 

•  Developing  architecture  as  a  specific  capability  of  the  organisation  in  its  future 
development; 
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•  Developing  an  integrated  architecture  capability  through  which  the  ADO  can 
understand,  develop  and  manage  the  Defence  Information  Environment  (DIE)  in 
an  efficient  and  cost  effective  manner;  and 

•  Maturing  the  ADO's  capability  in  C4ISR  systems  development  (including  planning, 
designing,  simulating/modelling  and  evaluating)  through  using  architecture 
practice. 

The  study  mainly  focuses  on: 

•  a  common  understanding  that  can  be  shared  by  all  relevant  parties, 

•  the  philosophy  of  achieving  a  mature  enterprise-wide  architecture  practice; 

•  the  context  and  management  study  of  ADO's  architecture  practice; 

•  architecture  practice  planning  and  decision  making;  and 

•  investigation  into  architecture  practice  as  a  fundamental  discipline  for  overall  IT 
practice  improvement. 

The  output  of  the  framework  study  of  architecture  practice  will  be  a  management 
framework  for  the  ADO  to  improve  its  IT  Development  Capability  (ITDC)  through 
using  architecture.  In  Phase  1  of  the  research  task,  the  study  initially  provides  academic 
and  technical  analysis  of  R&D  in  architecture  and  proposes  a  rudimentary  version  of 
such  a  framework.  This  framework  is  oriented  towards  achieving  effective  generation, 
management  and  re-use  of  knowledge  or  architecture  in  IT  practice. 

The  study  shows  that  developing  a  disciplined  architecture  practice,  which  includes 
architecture  products,  architectural  methodologies  and  supporting  environments, 
enhances  the  IT  development  capability.  A  better  understanding  of  IT  development 
capability  helps  us  in  planning  architecture  practice,  and  developing  overall  control 
mechanisms  for  architectural  methodology  coordination  and  architecture  product 
management. 

Specifically,  the  framework  study  on  architecture  practice  for  the  ADO  aims  to: 

•  Investigate  the  R&D  context  where  various  architectural  issues  arise  (discussed  in 
Part  1); 

•  Discuss  concepts  and  principles  of  architecture  and  architecture  frameworks 
(discussed  in  Part  1); 

•  Evaluate  and  compare  architecture-based  methodologies  (discussed  in  Part  1); 

•  Examine  current  architecture  practice  in  both  US  DoD  and  the  ADO; 

•  Identify  both  opportunities  and  difficulties  in  architecture  related  practice; 

•  Provide  a  management  framework  of  architecture  practice; 

•  Propose  strategic  directions  for  the  ADO  to  improve  IT  development  capability 
through  use  of  rationalised  architecture  practice; 

•  Develop  a  framework  for  the  ADO  to  plan  and  develop  an  Integrated  Architecture 
Capability  for  its  future  development,  including  C4ISR  domains; 
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•  Assist  the  ADO  in  the  planning  and  initialisation  of  architecture  related  R&D  in 
order  to  avoid  various  problems  caused  by  ill-planned  practice;  and 

•  Make  recommendations  on  process  innovation  and  initiatives  in  architecture 
practice. 

The  study  does  not,  however: 

•  Produce  any  design  of  architectures  for  particular  systems; 

•  Study  any  technology-dependent  integration  solution; 

•  Provide  specific  suggestions,  at  this  stage,  on  which  architecture  methodologies 
should  be  adopted  by  the  ADO; 

•  Attempt  to  make  any  architecture  decision  on  ADO's  behalf;  or 

•  Intend  to  educate  developers  in  detail  about  how  to  employ  particular 
methodologies. 


An  important  feature  of  this  study  is  its  comprehensiveness  in  addressing  broad 
architecture  issues  and  their  relationship  to  the  improvement  of  the  organisation's  IT 
development  capability. 

It  is  suggested  that  in  order  to  better  understand  issues  discussed  in  this  report,  that 
readers  first  peruse  the  Part  1  of  the  Phase  1  Report,  or  use  it  as  a  reference. 
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2.  Architecture  Practice  and  C4ISR  Capability 

Development 

The  US  DoD  C4ISR  Architecture  Framework  (C4ISR  Architecture  Working  Group, 
1997)  begins  with  the  following  quote: 

"The  Defence  Science  Board  and  other  major  studies  have  concluded  that  one  of  the  key  means 
for  ensuring  interoperable  and  cost  effective  military  systems  is  to  establish  comprehensive 
architectural  guidance  for  all  of  US  DoD." 

This  statement  demonstrates  the  US  DoD  belief  that  architecture  practice  is  required  to 
ensure  that  C4ISR  capabilities  meet  the  requirements  of  warfighters. 

The  main  reasons  for  the  ADO  to  consider  an  overall  architectural  guidance  are. 

•  In  order  to  successfully  deliver  improved  IT  capability  for  core  business  areas,  the 
ADO  needs  adequate  capability  to  effectively  generate,  manage  and  reuse 
knowledge  in  IT  practice  as  a  first  step  towards  an  improved  overall  development 
approach. 

•  Wide  use  of  the  concept  of  architecture  by  the  defence  community  requires  better 
methods  of  architecture  production  and  management  that  maximise  the  value  of 
architecture  and  architecture  practice. 

•  On  many  occasions  both  defence  and  industry  representatives  have  expressed  the 
belief  that  the  chaotic  situation  of  IT  practice  in  the  organisation  will  not  end  unless 
significant  cultural  change  and  process  innovations  are  introduced. 

C4ISR  systems  development  requires  the  organisation  to  pay  more  attention  to 
architecture  practice  rather  than  just  individual  architecture  products.  Without  a 
sophisticated  understanding  and  effective  management  of  architecture  practice,  it  is 
difficult  for  the  organisation  to  achieve  a  high  level  of  IT  development  capability  that 
could  meet  the  needs  of  knowledge-based  warfare. 

2.1  Use  of  Architecture  for  C4ISR 

The  task  of  C4ISR  systems  development  is  carried  out  in  an  evolutionary  development 
process  if  the  ADO  is  considered  as  a  whole.  It  involves  such  activities  as  planning, 
research,  system  development,  acquisition  and  support  and  management  of  individual 
systems,  as  well  as  the  overall  system  of  systems.  The  context  for  this  task  has 
gradually  formed  and  relied  on  a  body  of  knowledge,  which  covers  the  following 
areas: 

•  Individual  system/ capability  development  (the  systems  are  largely  developed  by 
industry  but  managed  by  the  Department); 

•  Capability  study  and  system  synthesis,  including: 

C2  capability  study; 

Military  Information  Operation  capability  study; 

Joint  Vision; 

Individual  concepts/systems  and  joint  systems  or  systems  of  systems  (SOS); 
System  or  SOS  simulation/ modelling. 
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•  IT  environment  study  and  development,  including: 

COE/Technical  Architecture  Framework  /Reference  Architecture; 
Interoperability; 

Standards/policy. 

•  Methodologies,  such  as: 

Architecture  frameworks; 

Software  Engineering  (SE); 

Domain  Engineering  (DE). 

Because  of  the  complexity  of  the  ADO's  IT  practice,  there  has  been  a  variety  of 
demands  in  using  concepts  of  architecture  and  architectural  methodologies.  It  should 
be  appreciated  that  many  individual  architecture  products  or  ad  hoc  architectural 
approaches  can  be  developed  and  used  to  address  certain  aspects  of  architecture 
practice.  On  the  other  hand,  however,  questions  and  confusion  generated  from  the 
practice  are  various,  with  these  falling  mainly  in  two  sectors: 

•  In  traditional  IT  practice,  such  as: 

Flow  can  architecture  products  be  developed  effectively  and  coherently? 

How  can  different  architectural  methodologies  be  well  coordinated  in  the  practice? 
Is  there  a  unified  architectural  methodology  that  meets  various  needs? 

How  can  architecture  be  used  to  improve  the  acquisition  process  of  IT  capability? 

•  In  C4ISR  capability  development,  such  as: 

How  can  C4ISR  and  warfighting  capability  development  be  supported  by 
architecture? 

How  can  an  architectural  methodology,  such  as  the  C4ISR  Architecture 
Framework,  and  its  products,  be  successfully  integrated  with  other  IT-related  R&D 
activities  and  the  culture  of  the  ADO,  so  that  architecture  practice  can  be  supported 
as  broadly  as  possible? 

How  can  the  C4ISR  Architecture  Framework  be  used  by  the  ADO  and  in  what 
manner? 

2.2  Roles  of  Architecture 

Traditional  disciplines  of  computing  and  information  systems  do  not  systematically 
address  how  the  complicated  task  of  developing  and  managing  C4ISR  systems  could 
be  carried  out  coherently  and  in  an  integrated  manner.  One  of  the  biggest  challenges  is 
the  formulation  of  an  overall  development  approach  that  can  meet  the  specific 
requirements  of  IT  development  capability  for  the  ADO,  while  ensuring  that 
individual  activities  can  be  conducted  coherently  within  a  given  context.  This  approach 
needs  to: 

•  Enable  outcomes  of  these  activities  to  be  successfully  integrated  and  maximally 
used  in  practice; 

•  Ensure  better  generation,  management  and  reuse  of  architecture  knowledge  so  that 
this  body  of  knowledge  can  be  treated  as  an  asset  of  the  organisation;  and 
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•  Lead  to  maturation  of  the  organisation's  IT  development  capability. 

Architecture  can  contribute  measurably  to  integration,  interoperability,  insertion  of 
technology,  cost  reduction  and  organisation  knowledge  management.  As  pointed  out 
in  Part  1  of  this  report,  the  roles  of  architecture  are  presented  in  die  three  distinct  areas 
in  which  architecture  is  used: 

•  A  picture  of  the  current  state; 

•  A  blueprint  or  vision  for  the  future;  or 

•  A  roadmap  as  guidance  on  how  to  get  there. 

For  any  specific  architecture  its  role  is  always  limited  to  one  of  these  and  varies 
depending  on  a  number  of  factors,  such  as  scope  and  comprehensiveness.  In  order  to 
get  the  full  benefits  of  architecture  from  all  its  three  main  roles,  an  integrated 
architecture  capability  is  required  by  the  ADO.  The  requirements  for  this  future 
development  capability  are  discussed  in  Section  5. 

The  development  of  an  integrated  architecture  capability  is  critical  to  the  defence 
organisation,  but  is  also  a  challenging  task.  Currently,  some  disparate  architecture 
capabilities  have  been  developed  independently.  Individual  architecture  capabilities 
and  roles  need  to  be  combined  to  jointly  provide  support  for  the  improvement  of  the  IT 
development  capability,  through  the  integrated  architecture  capability  generated  from 
well-planned  and  well-developed  architecture  practice. 
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3.  Experience  and  achievements  of  the  US  DoD 

In  order  to  improve  its  IT  development  capability,  in  particular  for  successful  and 
evolutionary  acquisition  of  C4ISR  capabilities,  the  US  DoD  has  started  to  develop  its 
practices  in  various  areas  of  architecture.  It  was  necessary  for  the  US  DoD  itself  to  do 
this  since  industry  practices  in  architecture  cannot  meet  its  specific  needs,  and  most  of 
them  independently  address  certain  issues  of  architecture  practice  required  for  the 
acquisition  process. 

3.1  Management  of  US  DoD  Architecture  Practice 

Issues  occurring  in  architecture  practice  management  have  attracted  attention  from 
various  levels  of  the  US  DoD.  Two  main  groups  were  set  up  to  assist  the  Office  of  the 
Assistant  Secretary  of  Defense  for  C3I,  USA,  in  developing  and  managing  the  overall 
architecture  practice  of  the  US  defence  organisation. 

C4ISR  Architecture  Working  Group  (AWG)  was  set  up  in  1996  with  representatives 
from  various  parts  of  the  Department  and  has  two  main  objectives: 

•  implementation  of  the  recommendations  made  by  the  Architecture  Panel  of  the 
C4ISR  Integrated  Task  Force  (ITF);  and 

•  identification  and  resolution  of  other  appropriate  C4ISR  Architecture  issues. 

Six  panels  were  formed  within  the  AWG  to  concentrate  on  six  different  areas: 

•  Architecture  Framework; 

•  C4ISR  Interoperability; 

•  Coalition  Issues; 

•  Architecture  Data  Models  and  Tools; 

•  US  DoD  Architecture  Roles  and  Responsibilities; 

•  Integration  of  the  five  areas  above. 


The  main  achievements  and  outcomes  are  briefly  discussed  in  the  following  section. 

Architecture  Coordination  Council  (ACC)  was  set  up  in  1997  and  has  an  action  arm 
called  the  Architecture  Coordination  Group  (ACG)  that  is  responsible  for  continuous 
guidance,  review,  integration  and  coordination  among  all  relevant  agencies.  Indeed,  it 
was  required  that  the  ACG  serve  as  the  executive  secretariat  of  the  ACC,  and  ensure 
that  all  work  of  the  ACC  and  its  supporting  groups  is  completed,  integrated  and 
brought  to  the  ACC  for  appropriate  review,  revision  and  approval. 

In  1998,  the  AWG  recommended  the  establishment  of  a  multi-domain  architecture 
working  group  with  appropriate  US  DoD  community-wide  representation  whose 
charter  would  be  to  support  the  US  DoD  CIO  in  developing  a  US  DoD  Information 
Technology  Architecture. 
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3.2  Achievements 

The  US  DoD  has  led  architecture  practice  in  the  area  of  C4ISR  during  the  last  two 
decades.  The  main  achievements  are  in  four  sectors: 

•  Supporting  Architecture  Products; 

•  Architecture  Methodologies; 

•  Architecture  Descriptions  and  Repositories; 

•  Supporting  Tools /Environments. 


Each  of  the  sectors  is  discussed  further  below. 

3.2.1  Supporting  Architecture  Products 

A  set  of  corporate-based  supporting  architecture  products,  also  called  universal  reference 
resources,  has  been  developed  in  the  US  DoD's  architecture  practice,  including. 

•  TAFIM  and  TRM 

The  Technical  Architecture  Framework  Information  Management  (TAFIM)  (version 
3.0)  (DISA,  1996[b])  is  a  set  of  eight  volumes  consisting  of  very  specific  guidance  on 
building  and  maintaining  US  DoD  systems  architectures.  It  provides  guidance  for 
the  evolution  of  the  US  DoD  technical  infrastructure.  The  TAFIM  does  not  provide 
a  specific  system  architecture.  The  TAFIM  US  DoD  Technical  Reference  Model  (US 
DoD  TRM)  defines  the  target  technical  environment  for  the  acquisition, 
development,  and  support  of  US  DoD  information  technology  through  proving  a 
common  conceptual  framework  and  a  common  vocabulary. 

•  CADM 

The  Core  Architecture  Data  Model  (CADM)  (CAWG,  1997[b])  is  intended  to 
provide  a  common  meta-model,  or  (logical)  schema,  for  repositories  of  architecture 
information.  It  enables  storage  of  architecture  products  from  multiple  framework- 
based  architecture  projects  in  a  common  way  such  that  products  from  different 
projects  can  be  jointly  analysed  and  compared. 

•LISI 

The  Levels  of  Information  Systems  Interoperability  (LISI)  is  a  product  that  supports 
users  at  all  levels  and  defines  a  maturity  model,  capabilities  and  implementation 
options,  and  an  interactive  process  for  improving  systems. 

•  DII  COE  r  ,  r. 

The  DII  Common  Operating  Environment  (DII  COE)  (DISA,  1996[a])  defines 
software  portability  and  application-to-operating  environment  interactions. 

•SHADE 

The  Shared  Data  Environment  (SHADE)  is  a  set  of  common  data  models. 

•  JOA/JSA/JTA 

The  Joint  Operational  Architecture  (JOA),  Joint  Systems  Architecture  (JSA)  and 
Joint  Technical  Architecture  (JTA)  are  three  main  views  that  jointly  with  other 
common  building  blocks  support  the  C4ISR  architecture  development  through 
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using  the  C4ISR  Architecture  Framework  described  later  in  this  section.  JTA 
establishes  the  minimum  set  of  rules  governing  information  technology  within  US 
DoD  systems,  including  standards  for  information  processing,  information  transfer, 
the  structure  of  information  and  data,  human-computer  interface  standards  for 
information  entry  and  display,  and  information  security  standards.  JTA  is  based  on 
previous  works  of  TAFIM,  TRM  and  DI  COE. 

JSA  and  JOA  are  yet  to  be  developed. 

•  JTF  Reference  Architecture 

The  Joint  Task  Force  (JTF)  Reference  Architecture  is  a  specification  of  the  US  DoD 
force  structure  and  operational  guidance. 

•  C4ISR  Architectures  for  the  Warfighter  (CAW) 

The  C4ISR  Architectures  for  the  Warfighter  (CAW)  Program  develops  critical 
C4ISR  baseline  (Contingency  Planning)  and  objective  architectures  (investment 
decisions)  and  companion  TTPs  at  the  Unified  Commands.  This  program  begins 
with  the  original  CIAP  organisational  focus — the  CINC/JFC  level  with 
contributions  from  National  Agencies,  the  Sendees,  and  the  Supporting  Commands 
— and  extends  this  focus  from  the  JFC  down  through  the  Joint  Force  functional  and 
service  components.  In  other  words,  it  begins  with  an  overarching  Command 
C4ISR  Architecture  (CCA)  which  spans  all  UJTL  functional  areas  and  bounds  the 
C4ISR  scope.  The  analysis  is  then  further  focused  through  the  development  of  three 
core  architectures:  a  Command  and  Control  (C2)  architecture;  an  Intelligence 
Surveillance  and  Reconnaissance  (ISR)  architecture;  and  a  Communications  and 
Computers  Infrastructure  architecture.  The  C2  and  the  ISR  architectures  directly 
map  to  a  primary  "C4ISR"  UJTL  task,  while  the  Computers  and  Communications 
Infrastructure  architecture  transcends  and  underpins  all  UJTL  tasks.  All  CAW 
architectures  are  developed  using  a  common  structured  approach,  the  C4ISR 
Architecture  Framework  2.0  discussed  in  the  next  subsection. 

Although  these  supporting  products  have  been  or  will  be  developed  by  different  teams 
for  various  reasons,  a  common  purpose  shared  by  them  is  to  eventually  and  globally 
support  better  architecture  practice  as  a  whole  rather  than  only  for  use  of  the  C4ISR 
Architecture  Framework.  Considering  these  products  as  a  set  and  applying  the  context 
analysis  in  Part  1,  it  is  noted  that  an  architecture  practice  supporting  environment 
(APSE)  for  the  US  DoD  is  being  gradually  formed.  One  of  the  main  challenges  in 
architecture  for  the  US  DoD  is  whether  these  products  can  be  successfully  used  in  a 
combined  maimer  and  maintained  or  evolve  consistently  and  coherently  in  practice. 

3.2.2  Architecture  methodologies 

•  C4ISR  Architecture  Framework 

This  has  been  developed  as  a  methodology  for  guiding  development  of 
architecture  descriptions  for  warfighting  domains  and  is  also  suggested  for  use 
more  broadly  within  US  DoD.  The  framework  intends  to  provide  general  guidance 
for  coherent  use  of  a  variety  of  IT  achievements  of  US  DoD  mentioned  above  for 
C4ISR  systems  development. 

The  C4ISR  Architecture  Framework  suggests  that  all  development  projects  should 
adopt  a  unified  architecture  framework  for  integration  of  operations  and  systems. 
This  means  that  in  the  course  of  building  a  given  architecture  description,  a  set  of 
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architecture  products  of  those  graphical,  textual  and  tabular  items  will  be 
developed.  Some  products  in  this  set  are  essential  and  some  are  supporting 
products.  Using  this  framework,  the  US  DoD  is  aiming  to  consistently  define  all 
C4ISR  relevant  system  architectures  using  three  main  views,  that  is.  Operational 
Architecture,  System  Architecture  and  Technical  Architecture.  However,  these 
efforts  will  be  carried  out  separately  on  a  project  basis.  It  is  stated  that  all  existing 
systems  are  to  be  re-described  at  some  stage  in  this  unified  representation. 

The  C4ISR  AF  is  a  specific  architecture  development  methodology  for  the  C4ISR 
domain. 

•  C4ISR  Models 

In  late  1996,  the  C4I  Modelling,  Simulation,  and  Assessment  Directorate  (D8)  of 
DISA  took  an  innovative  approach  and  began  developing  the  DISA  C4ISR  Model. 
The  purpose  of  the  model  was  to  enhance  the  understanding  of  how  information 
affects  decision  making.  The  DISA  C4ISR  Model  is  a  High  Level  Architecture 
(HLA)  compliant  federation  using  a  modified  Rimtime  Infrastructure  (RTI)  based 
upon  the  HLA  RTI  version  0.33  developed  by  the  Defense  Modeling  and 
Simulation  Office  (DMSO).  Migration  to  the  new  HLA  RTI  version  1.3  is  forecast 
to  be  completed  in  FY99. 

•  Organisation  Domain  Modelling  (ODM) 

Organisation  Domain  Modelling  (Simos,  1996)  is  a  domain  engineering  method 
developed  in  1996  under  the  Software  Technology  for  Adaptable,  Reliable  Systems 
(STARS)  program  and  sponsored  by  the  U.S.  Defense  Advanced  Research  Project 
Agency  (DARPA).  ODM  builds  on  concepts  that  have  emerged  from  the  work  of 
many  researchers  and  practitioners  in  the  field  of  systematic  software  reuse.  The 
systematic  reuse  community  has  evolved  the  discipline  known  as  domain 
engineering  in  an  attempt  to  formalise  software  engineering  processes  and  make 
the  design  of  reusable  software  more  repeatable,  verifiable  and  methodical.  The 
ODM  method  consists  of  three  main  phases,  referred  to  as  domain  planning,  domain 
modelling,  and  asset  base  engineering.  Although  this  approach  was  originally 
introduced  for  improvement  of  software  reusability,  it  has  also  suggested 
systematic  improvement  in  handling  domain  models  or  architectures  as 
organisational  assets. 

3.2.3  Architecture  descriptions  and  repositories 

There  are  a  great  number  of  descriptive  products  associated  with  existing  systems  in  a 
diversity  of  representation  forms  from  past  development  in  various  domains  within 
the  US  DoD. 

There  has  been  no  reporting  of  any  efforts  that  aim  to  achieve  an  overall  and  integrated 
architecture  description  for  all  existing  systems  of  the  US  DoD.  However,  it  was 
mentioned  that  the  C4ISR  Architecture  Framework  would  also  be  used  for  re¬ 
describing  existing  systems.  It  is  not  clear  at  this  stage  how  the  redescription  of  all 
existing  systems  is  related  to  the  development  of  the  Joint  Systems  Architecture  (JSA). 

A  US  DoD  Architecture  Information  Repository  (CAWG,  1998  [b])  will  be  developed 
to  provide  for  recording,  and  making  available  for  review  and  reuse,  instances  of 
architectures  and  their  architecture  descriptions.  Starting  points  for  the  repository 
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would  be  the  Integrated  Data  Dictionaries  for  the  Joint  Technical  Architecture  and  the 
Joint  Operational  Architecture. 

3.2.4  Supporting  tools/ environments 

•  Joint  C4ISR  Architecture  Planning/ Analysis  System  (JCAPS) 

JCAPS  is  a  supporting  tool  designed  to  facilitate  use  of  the  C4ISR  Architecture 
Framework  through  access  to  supporting  elements  or  universal  references.  It  aims 
to  provide  its  users  with  flexibility  by  allowing  them  to  query  the  database  in 
previously  unthought  of  ways,  discovering  new  relationships  and  more 
meaningful  ways  to  show  why  and  how  those  C4ISR  capabilities  are  to  be 
integrated.  JCAPS  prototypes  produced  during  the  first  of  two  phases  of  a  4-phase 
development  have  been  completed.  Integrating  JCAPS  with  other  supporting 
elements  (such  as  LISI  and  CADM)  will  generate  more  functions  for  various 
architecture  purposes  in  broader  areas. 

3.2.5  Other  initiatives 

•  US  DoD  Architecture  Framework  is  referred  to  in  the  Final  Report  of  the  C4ISR 
Architecture  Working  Group  but  there  is  no  detailed  discussion. 

•  US  DoD  Architecture  Information  Repository  is  also  referred  to  in  the  Final 
Report  of  the  C4ISR  Architecture  Working  Group  but  again  there  is  no  detailed 
discussion. 

•  Evolutionary  Design  of  Complex  Software  (EDCS) 

EDCS  is  a  program  sponsored  by  DARPA  which  summarises  technologies  into  five 
technology  "clusters":  1)  Rationale  Capture  and  Software  Understanding;  2) 
Architecture  and  Generation;  3)  High  Assurance  and  Real-time;  4)  Design 
Management,  and  5)  Dynamic  Languages. 

3.3  Discussion 

US  DoD  initiatives  in  architecture  are  both  numerous  and  diverse.  The  achievements 
mentioned  above  are  those  within  the  authors'  knowledge  that  they  regard  as  relevant. 

Since  the  C4ISR  architecture  framework  is  a  mandated  methodology  for  all  US  DoD 
projects,  all  new  systems  for  warfighting  should  be  developed  using  it  and  with  a 
whole  set  of  architecture  products.  The  framework  specifies  which  architecture 
products  are  required  but  does  not  elaborate  on  how  the  architecture  products  should 
be  developed  in  detail,  such  as  through  which  processes  and  using  which  tools  and 
techniques. 

The  evolution  process  of  the  C4ISR  Architecture  Framework  illustrated  in  Figure  3-1 
shows  the  planned  development  (CAWG,  1998  [b])  to  cover  broader  areas  of  the  US 
DoD's  IT  development  capability. 
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Endorsement 


Figure  3-1.  Evolution  process  of  the  C4ISR  Architecture  Framework 

The  trend  is  towards  a  unified  C4ISR  development  process  suggested  by  the  AWG. 

This  process  will  use  a  unified  architecture  practice  supporting  environment  including 

a  set  of  universal  reference  resources  (or  corporate  supporting  elements).  However, 

relationships  are  yet  to  be  clearly  defined  between  or  amongst  the  following  elements 
(CAWG,  1998[b]): 

•  C4ISR  Architecture  Framework  plus  universal  reference  resources  (common 
building  blocks); 

•  US  DoD's  Architecture  Framework  (to  be  developed); 

•  US  DoD's  Information  Technology  Architecture  (to  be  developed);  and 

•  US  DoD's  Architecture  Information  Repository  (to  be  developed). 

Unfortunately,  the  progress  in  these  areas  has  not  been  further  reported. 

The  investigation  into  the  current  architecture  practice  of  the  US  DoD  shows  that: 

•  An  organisational  commitment  to  architecture  has  been  made; 

•  The  architecture  practice  as  a  whole  needs  to  be  further  defined  when  the  strategic 
and  global  thinking  relating  to  architecture  practice  becomes  significantly  clearer  to 
all  relevant  areas; 

•  Management  and  coordination  concerns  need  to  be  addressed  to  facilitate  its 
successful  evolution; 

•  The  core  and  worthwhile  part  of  the  practice  will  become  evident  as  more  activities 
are  carried  out  using  the  various  architecture  products  and  approaches;  and 

•  The  IT  development  capability  of  the  organisation  will  be  improved  significantly  if 
tools  or  environments,  such  as  JCAPS,  can  be  properly  developed  to  integrate 


12 


DSTO-CR-0152 


architecture  products  and  support  use  of  architectural  approaches  (or  architecture 
frameworks). 


Components  to  be  developed 


Existing  Common  Building  Blocks 


Figure  3-2.  An  architectural  approach  of  the  US  DoDfor  developing  C4ISR  systems. 


The  unified  C4ISR  development  process  proposed  by  the  US  DoD  C4ISR  AWG  shows 
that  in  the  process  there  are  other  important  aspects  that  are  not  covered  by  the 
Architecture  Framework.  It  is  very  important  to  understand  that  any  architecture  or 
framework  does  not  address  the  full  range  of  problems  and  issues  that  are  likely  to  be 
experienced  in  SOS  development.  Ideally,  this  unified  process  would  work  as  follows 
(CAWG,  1998[b]): 

•  Distributed  development  of  C4ISR  operational,  systems  and  technical  architecture 
views  would  continue; 

•  Architectures  would  be  easily  compared  and  interrelated  across  organisational 
boundaries  due  to  common  look,  touch,  and  feel; 

•  The  US  DoD  components  would  leverage  the  integrable  architecture(s)  to: 

-  Discuss  and  reconcile  differences  regarding  common  joint  interactions 

-  Examine  applications  of  current  and  emerging  technology 

-  Look  for  leveraging  opportunities 

-  Identify  and  prioritise  key  systems  interoperability  problems  and  objectives 

•  Less  obvious  concepts  would  be  tested  for  validity  and  cost-effectiveness  prior  to 
committing  to  a  potentially  costly  acquisition  or  full-scale  integration  activity; 

•  Notions,  ideas,  concepts,  limited  demonstrations,  and  fielded  capabilities  could  be 
traced  back  through  the  architecture  audit  trail  to  assess  the  impact  on  operational 
mission  effectiveness. 


Therefore,  the  AWG  is  aiming  to  enable  the  framework  to  evolve  and  to  be  integrated 
with  a  broader  practice  environment  of  IT  business. 


Based  on  the  architecture  practice  context  analysis  in  Part  1,  we  can  map  the  current  US 
DoD  architecture  practice  for  C4ISR  onto  the  high  level  conceptual  outline  of  the 
recommended  architecture  practice  as  illustrated  in  Figure  3-3. 
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Figure  3-3.  Coverage  examination  of  US  DoD's  main  architecture  activities  in  C4ISR 

Note  that  the  US  DoD  did  not  choose  to  use  any  Enterprise  Architecture  approach 
developed  by  industry  to  either  initialise  its  enterprise  architecture  development  or 
guide  its  architecture  practice  as  a  whole.  Due  to  the  lack  of  definition  of  the  DoD 
enterprise  architecture  and  incompleteness  of  the  specifications  of  JOA  and  JSA,  it  is 
difficult  at  present  to  draw  an  outline  of  the  US  DoD-wide  enterprise  architecture 
solution. 

The  US  DoD's  experience  and  achievements  are  certainly  important  for  the  ADO. 
Selective  use  of  some  US  DoD  achievement  in  architecture  will  not  only  reduce  costs 
for  the  ADO  but  also  ensure  to  a  certain  degree  interoperability  with  the  US  DoD.  It 
must  be  realised,  however,  that  there  are  certain  difficulties  and  risks  if  they  are 
applied  as  total  solutions  to  ADO's  problems  because  of  the  differences  in  practice  and 
culture  between  the  two  organisations. 
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4.  An  Historical  Overview  of  ADO  Architecture 

Practice 

DSTO  started  work  in  architecture  for  the  ADO  about  a  decade  ago  with  the  work  by 
Andrews  et  al  (1989),  which  addressed  an  Integrated  Australian  Defence 
Communications  Architecture.  Sobolewski  (1992)  extended  the  research  into  the 
broader  area  of  C3I,  as  a  consequence  of  the  growing  awareness  of  the  importance  and 
complexity  of  C3I  architectural  issues.  Based  on  the  understanding  at  that  time,  a  goal 
C3I  architecture  based  on  layering  principles  was  proposed.  Sobolewski's  study 
suggested  that  a  C3I  System  Development  Architecture  should  be  used  as  a  base  of 
"Evolutionary  Acquisition",  which  includes  "Evolutionary  Development". 

In  1996,  the  Distributed  Systems  Technology  Centre  CRC  (DSTC)  conducted  a  study 
sponsored  by  DSTO  on  issues  in  C3I  architectures.  Its  Phase  II  report  (DSTC,  1997) 
describes  architecture  issues  with  a  broad  coverage,  ranging  from  technologies  to 
methodologies.  These  included  many  of  the  US  DoD's  initiatives,  but  the  focus  was 
mainly  on  how  distributed  computing  technologies,  such  as  CORBA,  could  address 
certain  issues. 

With  support  from  industry,  the  Battle  Command  Support  Systems  (BCSS)  project 
used  an  architectural  approach  in  1998.  This  involved  the  use  of  The  Open  Group 
Architecture  Framework  (TOGAF),  and  was  used  mainly  for  technical  architecture 
description  and  development. 

From  1996  to  1998,  the  Information  Architectures  Group  at  DSTO  conducted  the  C2 
Support  Study  (Clothier,  1997  [a]  and  [b]),  which  investigated  the  IT  capability 
required  by  the  ADF  under  a  variety  of  different  operational  deployment  scenarios. 
The  study  pointed  out  that  in  order  to  better  use  information  to  support  the  defence 
capability,  a  defence  information  environment  (DIE)  should  be  developed  and 
rationalised  through  use  of  an  architectural  approach. 

Architectures  are  being  developed,  throughout  defence  and  have  been  for  a  long  time. 
However,  these  architectures  are  principally  for  and  within  individual  projects. 
Currently,  there  is  a  trend  toward  individual  projects  that  address  larger  and  more 
complex  development  issues  such  as  Joint  System  synthesis  and  simulation  and  joint 
systems  for  C4ISREW.  Also,  there  are  now  systems  with  a  broad  coverage,  such  as 
JCSS  and  JISS. 

Alison's  paper  (Alison,  1997)  discusses  the  need  for  the  development  of  an  Enterprise 
Architecture  Framework  for  C4ISR  in  tire  Australian  military  enterprise.  The  Enterprise 
Architecture  presented  is  not  an  enterprise  design,  being  rather  a  set  of  expressions 
that  describe  the  relationships  between  the  elements  and  tasks  of  a  designated 
enterprise,  and  the  information  flows  between  them. 

There  are  also  a  number  of  current  DSTO  research  tasks  that  use  the  concept  of 
architecture.  These  focus  on  different  aspects  of  architecture  use  or  development  for 
various  areas  of  the  ADF,  including  the  Battlespace  Communications  System  (Land) 
Architecture  (JNT99/141),  the  Core  Communications  Architecture  (JNT99/150),  C4ISR 
architecture  simulation  and  assessment  (JNT99/138),  Joint  C4ISREW  SOS  (JNT00/007) 
and  Operational  Architectures  (JNT99/018).  These  tasks  will  generate  various 
architecture  products  and  architecture  capabilities. 
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The  Architecture  Prachce  Study,  of  which  this  report  is  a  part,  was  started  in  April  1999 
to  investigate  architecture  issues  in  an  inclusive  manner.  By  taking  a  different 
perspective,  the  study  examines  the  broad  context  of  architecture  issues  and  related 
activities,  and  investigates  their  connections  or  interrelationships.  This  will  allow  a 
comprehensive  and  mature  understanding  of  the  practice  to  be  obtained.  Questions  to 
be  addressed  include: 

•  What  is  the  rationale  behind  the  ADO's  architecture  practice? 

•  How  can  the  architecture  practice  be  successfully  planned  and  managed? 

•  Which  architecture  products  developed  by  other  agencies  or  organisations  (e.g.  US 
DoD)  can  be  adopted  or  tailored  by  the  ADO,  and  how? 

•  Which  architecture  products  must  be  developed  by  the  ADO  and  how? 

•  How  will  the  ADO's  architecture  prachce  evolve  in  the  future? 

•  How  should  an  environment  be  developed  that  is  conducive  to  and  supportive  of 
enterprise  architecture  prachce  as  part  of  the  normal  business  process? 

•  How  can  an  integrated  architecture  capability,  including  describing,  visualising, 
simulating  and  evaluating,  gradually  be  developed  to  support  future  C4ISR 
capability  development? 

•  What  current  processes  would  be  displaced  if  an  enterprise  architecture  prachce 
was  to  be  adopted? 

Learning  from  successful  prachces  certainly  will  help  the  organisahon  to  improve  its 
own  prachce.  Using  the  same  architectural  approach,  such  as  the  C4ISR  Architecture 
Framework  if  applicable,  however,  does  not  have  to  mean  the  same  architecture 
practice.  Unlike  a  simple  process,  architecture  prachce  cannot  be  easily  copied  from 
other  organisahons,  since  it  is  or  has  to  be  embedded  in  the  culture  of  an  organisation. 
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5.  Requirements  and  Challenges  of  ADO  IT 
Development  Capability 

Knowledge-based  warfighting  capability  requires  the  ADO  to  be  equipped  with 
adequate  information-based  supporting  capability.  In  order  to  meet  the  changing 
requirements  of  its  core  business,  new  IT  capabilities  will  be  developed  and  the 
existing  capabilities  will  need  to  change  or  evolve  as  the  organisation  changes  and 
technology  advances. 

As  mentioned  in  Part  1,  IT  development  capability  is  the  power  possessed  by  the 
organisation  in  knowing  what  and  how  to  develop  and  support  this  IT  capability,  and 
implementing  it  efficiently  and  cost-effectively  in  its  IT  practice. 

Developing  adequate  capability  for  IT  development,  which  is  the  capability  of  the 
organisation  to  run  its  IT  business,  is  a  great  challenge.  Unlike  certain  organisations 
that  can  largely  use  external  resources  for  developing  their  IT  capability,  the  ADO  has 
to  develop  its  own  IT  development  capability  for  its  specific  requirements,  although 
elements  of  this  capability  can  use  IT  development  capabilities  provided  by  industry. 

In  current  IT  practice,  the  IT  development  capability  of  the  ADO  is  provided  jointly  by 
a  number  of  players  as  shown  in  Figure  5-1,  including: 

•  Defence  Information  Systems  Group  (DISG); 

•  Defence  Acquisition  Organisation  (DAO); 

•  IT  staff  working  in  various  parts  of  the  ADO; 

•  DSTO; 

•  other  members  of  the  ADO;  and 

•  Industry,  both  Australian  and  foreign. 


Whether  IT  development  capability  is  adequate  for  the  needs  of  the  organisation  is 
determined  not  only  by  the  amount  of  resources  allocated,  but  also  the  way  in  which 
they  are  used. 

The  reality  of  evolutionary  development  of  systems-of-systems  shows  that  the 
requirements  for  an  organisation's  overall  IT  development  capability  differ  from  what 
is  required  for  developing  a  single  system.  In  the  case  of  the  ADO,  the  ability  to  use 
individual  IT  technologies,  such  as  writing  a  piece  of  code  in  a  particular  language  for 
a  specific  application,  is  certainly  still  an  important  aspect  of  the  IT  development 
capability.  But  this  capability  by  itself  is  not  enough.  Indeed,  the  ADO's  IT 
development  capability  is  being  challenged  by  various  difficulties  and  problems 
encountered  in  evolutionary  acquisition  of  C3I  systems.  For  instance,  it  has  often  been 
observed  that  interoperability  is  not  a  purely  technical  issue.  Any  specific  and  well- 
defined  system  integration  or  data  conversion  can  be  quickly  implemented  through 
many  different  technology-dependent  solutions.  The  difficulty  of  interoperability  for 
the  ADO,  in  fact,  lies  in  achieving  full  specification  of  enterprise-wide  interoperability 
requirements  for  the  core  business  within  the  context  of  existing  IT  capability  and 
future  development. 
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Figure  5-1 .  Providers  of  IT  development  capability  for  the  ADO. 


Another  important  issue  observed  in  the  current  ADO  IT  development  capability  is 
that  although  people  have  realised  the  importance  of  organisational  knowledge,  the 
actual  level  of  knowledge  sharing,  management  and  reuse  is  not  satisfactory.  The 
reasons  for  this  are: 


•  There  is  no  clearly  defined  organisational  knowledge  value  chain; 

•  There  is  no  well-developed  common  environment  to  support  knowledge  creation, 
management  and  reuse  cross  the  organisation;  and 

•  There  has  been  no  adequate  organisational  culture  or  defined  process  to  ensure 
knowledge  reuse  and  preservation. 

For  most  organisations,  including  the  US  DoD  and  the  ADO,  the  IT  development 
capability  has  been  built  on  a  basis  of  individual  system  development,  where  each 
system  has  basically  been  developed  independently.  Individual  capabilities  m  IT 
practice  are  always  partly  and  individually  demonstrated  in  those  areas  of  the  body  of 
knowledge  for  C4ISR  systems  development  mentioned  in  the  previous  section.  The 
formation  of  the  general  IT  development  capability  is  basically  "as  it  grows  naturally" 
or  "bottom-up"  practice  rather  than  through  effective  overall  planning.  One  of  the 
reasons  for  this  is  that  since  traditional  software  engineering  approaches  are  designed 
mainly  for  "one  at  a  time"  system  development  projects.  Such  a  development  model 
leads  to  an  IT  development  capability  that  is  unable  to  successfully  and  effectively 
support  SOS  development  in  an  evolutionary  manner  in  the  context  of  a  large 
organisation. 

The  maturity  of  IT  development  capability  is  determined  by  the  abilities  in  many 
different  areas  of  IT  practice,  including  business  and  technology  planning,  design, 
acquisition,  implementation,  maintenance  and  evolution.  The  ADO  has  demanding 
requirements  in  all  these  areas.  Defining  proper  IT  development  capability  for  the 
ADO  is  thus  important  and  should  be  considered  by  the  senior  leadership  of  the 
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organisation.  Maturation  of  the  IT  development  capability  is  critical  to  the  success  of  its 
IT  practice. 

The  following  sections  discuss  how  the  ADO  can  and  should  improve  the 
organisation's  IT  development  capability  through  using  the  architecture  practice 
shown  in  Figure  5-2. 


Figure  5-2.  The  recommended  Architecture  Practice. 
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6.  Philosophy  and  Strategic  Directions 

The  history  and  current  activities  in  architecture  across  the  ADO  have  shown  a  kind  of 
architecture  practice,  which  had  no  overall  planning  on  the  basis  of  any  specific 
architecture  practice  model.  If  architecture  is  to  be  an  important  concept  used  by  the 
organisation  in  its  future  development,  this  current  practice  must  change  in  order  to 
generate  a  more  advanced  and  integrated  architecture  capability. 

In  the  current  IT  practice  of  the  ADO,  apart  from  the  daily  business  of  IT  as  described 
in  Section  2.1,  there  have  been  a  number  of  important  initiatives  that  require  a  common 
understanding  about  architecture  practice,  in  particular  in  a  SOS  context. 

•  Defence  Information  Environment  Board  (DIEB) 

As  the  Defence  Executive  in  IT,  the  DIEB  has  not  only  the  responsibility  but  also  the 
power  and  authority  to  determine  what  kind  of  IT  development  capability  the 
ADO  should  develop  for  itself.  Additionally,  the  DIEB  requires  adequate  support 
in  both  thinking  and  measures  for  strategic  decision  making,  as  well  as  running  the 
improved  IT  business  in  an  innovative  manner.  Some  studies  and  documents  have 
mentioned  or  described  certain  concepts  of  architecture,  such  as  the  DIE 
Architecture  and  the  DIE  Architecture  Framework.  It  is  important  now  for  the 
DIEB  to  reach  clear  definitions  of  these  concepts  and  embed  or  link  them  properly 
into  an  overall  development  approach.  Success  in  the  design  and  development  of 
the  DIE  will  be  determined  by  whether  a  high  level  IT  development  capability  can 
been  generated  that  specifically  meets  the  requirements  of  the  ADO. 

•  Development  of  Headquarters  Australian  Theatre  (HQAST)  and  Deployable  Joint 
Force  Headquarters  (DJFHQ) 

Development  of  various  headquarters  and  command  centres  for  the  ADO  requires 
an  advanced  capability  in  IT  development  that  should  be  reliable,  repeatable, 
efficient  and  cost-effective.  This  capability  should  ensure  that  the  developed  IT 
capabilities  for  the  ADF  adequately  meet  the  needs  of  knowledge-based  warfare, 
including  providing  a  high  level  of  interoperability.  It  must  be  noted  that  such  IT 
development  capability  has  not  been  generated  yet,  and  is  difficult  to  reach 
through  the  existing  IT  practice.  Achieving  the  required  capability  will  necessitate 
a  significant  change  in  culture  and  the  methods  of  handling  knowledge  of 
Information  Systems. 

•  TAKARI  Program 

The  Takari  Program  addresses  one  of  today’s  greatest  military  challenges: 
dispelling  the  fog  of  war  by  collecting  raw  information,  converting  it  into  useable 
knowledge,  and  making  it  available  to  the  commander  who  needs  it,  at  the  right 
time,  in  the  right  quantity  and  in  the  right  format.  Takari  is  not  a  single  project.  It  is 
a  program  of  separate,  but  related,  research  and  development  (R&D)  projects 
running  from  1996  to  2010,  which  are  designed  to  help  the  ADO  realise  its  vision  of 
an  integrated  C3I/IO  capability.  Successful  development  of  the  integrated  C3I/IO 
capability  requires  full  establishment  of  the  body  of  knowledge  in  all  related  areas 
of  IT  and  C3I/IO. 

Achieving  the  aims  and  objectives  of  the  Takari  Program  will  test  the  R&D 
capability  of  DSTO.  One  of  the  critical  parts  of  the  DSTO  capability  is  the  IT 
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development  capability.  This  can  be  demonstrated  at  different  levels,  including: 
invention  and  use  of  new  technologies  for  CTDs;  development  of  new  concepts; 
and  process  innovation  and  methodologies  to  support  both  partial  and  global 
improvement  to  the  IT  development  capability  of  the  ADO. 

Joint  systems  studies  required  by  the  ADF  necessitate  that  DSTO  develop  adequate 
R&D  capabilities  for  better  SOS-related  understanding,  development,  synthesis  and 
modelling. 

•  The  Knowledge  management  of  the  ADO 

In  the  concept  paper  on  Knowledge  Management  (O'Neill,  1998),  it  was  pointed 
out  that  "Defence  is  unlikely  to  achieve  the  Knowledge  Edge  without  a 
considerable  improvement  in  the  organisation's  ability  to  retain,  build  upon  and 
exploit  knowledge...  Specifically,  we  must  stop  knowledge  being  lost  when 
personnel  depart  or  are  posted". 

As  one  of  the  key  business  domains  of  Defence,  IT  practice  itself  is  facing  great 
challenges  and  requires  innovation  in  knowledge  management  because  of  the 
symptoms  mentioned  in  the  introduction  to  the  Part  1.  Rationalised  and  well- 
planned  organisation-wide  architecture  practice  will  lead  to  not  only  an 
environment  for  creation,  management  and  evolution  of  organisational  knowledge, 
but  also  to  a  cultural  change  in  IT  practice.  This  environment  can  effectively 
underpin  the  required  improvement  in  the  organisation's  knowledge  management 
capability. 

Remark 

In  order  to  develop  enterprise  solutions  in  architecture  for  the  ADO,  it  is  important 
to  properly  define  and  specify  the  relationships  between  these  efforts  and  their 
outcomes.  Do  we  have  an  effective  approach  to  relate  these  efforts  and  rationalise 
the  relationships  and  connections  between  them?  Can  we  use  an  approach  such  as 
the  C4ISR  architecture  framework  or  META  Group  EAS  to  do  this  job? 

The  Architecture  Practice  Study  reveals  that  any  specific  architecture  framework  or 
approach  in  most  cases  only  partially  addresses  architecture  issues  of  a  large 
organisation,  and  has  difficulties  achieving  satisfactory  results  individually.  Therefore, 
what  is  required  is  a  practice  that  allows  the  successful  combination  of  different 
frameworks  and  approaches. 

As  pointed  out  by  many  DSTO  studies,  an  overall  development  approach  should  be 
defined.  The  main  challenge  in  defining  such  an  approach  is  how  we  can  organise 
these  relevant  activities  into  a  rationalised  and  unified  development  framework. 

Based  on  the  comprehensive  analysis  of  architecture  and  its  context  presented  in  Part  1, 
the  architecture  practice,  as  shown  in  Figure  5-2,  recommended  to  the  ADO  has  the 
following  main  objectives: 

•  To  develop  a  framework  to  support  examination  and  improvement  of  IT 
development  capability; 

•  To  engineer  knowledge  of  information  systems  and  covert  it  into  reusable 
organisational  assets; 

•  To  achieve  a  framework  to  integrate  and  manage  IT  practice  disciplines; 
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•  To  conduct  the  practice  with  clear  strategic  directions  for  defining,  developing  and 
managing  architecture  products,  architecture  construction  processes  and 
supporting  environments;  and 

•  To  provide  a  platform  for  improved  knowledge  management  in  all  defence 
business  domains  related  to  IT,  including  C4ISR. 


The  most  important  features  of  this  architecture  practice  include: 

•  In  terms  of  coverage,  it  includes  architecture  products,  processes  and 
tools/environments,  and  it  is  much  broader  and  complete  than  any  single 
architecture  or  architecture  framework; 

•  It  is  based  on  architecture  capability  concepts  that  are  above  any  specific 
architecture  (product)  development; 

•  It  uses  an  architecture  knowledge  value  chain  to  link  or  relate  different  aspects  of 
architecture  practice; 

•  It  suggests  that  more  attention  be  paid  to  architecture  practice  planning  and 
management;  and 

•  It  suggests  that  all  architecture  developers  need  to  clearly  see  the  specific  context  in 
which  they  generate  architecture  —  what  system  the  architecture  is  associated  with, 
which  views  it  includes,  which  role  (descriptive  or  supporting)  it  plays,  how  the 
role  is  implemented,  how  it  can  be  used  and  reused  over  time  across  the 
organisation  as  an  asset,  and  how  the  architecture  can  or  should  be  developed. 

When  compared  with  the  US  DoD  achievements,  the  ADO  is  facing  the  following 
strategic  issues: 

•  How  can  architecture  practice  be  successfully  planned,  managed  and  coordinated 
from  both  technical  and  management  viewpoints? 

•  How  can  the  ADO  make  use  of  architecture  products  developed  by  other  agencies 
and  organisations,  e.g.  US  DoD? 

•  How  can  architecture  practice  help  to  achieve  effective  integration  of  related 
business  areas  in  IT  and  capability  development,  which  must  fit  the  organisational 
culture  of  the  ADO? 

•  What  resources  are  required  for  improving  ADO  architecture  practice  and  how 
should  they  be  used? 

The  philosophy  suggested  by  the  Architecture  Practice  Study  for  the  ADO  is  to  use  an 
integrated  IT  development  capability  model  discussed  in  the  next  section  to  relate 
various  aspects  of  architecture  issues.  This  model  can  be  used  in  combination  with  the 
recommended  Architecture  Practice  Model  shown  in  Figure  5-2  to  generate  overall 
guidance  or  enterprise  solutions  in  architecture  for  the  ADO. 
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7.  An  IT  Development  Capability  Model 

As  discussed  in  Section  5,  the  IT  sector  and  other  relevant  parties  of  the  ADO,  in 
conjunction  with  industry,  are  in  an  "enterprise"  that  provides  IT  capability  for  the 
organisation.  It  is  observed  that  we  have  not  defined  and  developed  a  suitable 
"business  model"  or  working  paradigm  for  our  IT  practice  to  efficiently  and  cost- 
effectively  deliver  the  IT  capability  required.  Therefore,  it  is  not  clear  what  kind  of  IT 
development  capability  the  ADO  should  possess  nor  how  it  should  operate  in  terms  of 
generating  deliverables  and  managing  processes  efficiently  and  cost-effectively. 

As  one  of  the  main  outcomes  of  this  framework  study,  we  propose  a  high-level 
working  paradigm  (or  framework)  of  IT  development  capability  for  the  ADO  as  shown 
in  Figure  7-1.  Through  this  paradigm,  we  study  the  ADO's  needs  in  architecture 
practice  in  association  with  five  components  of  IT  development  capability. 

In  order  to  ensure  that  at  a  high  level  integration  of  IT  development  capabilities  in 
different  areas  is  achievable,  the  effective  generation,  management  and  reuse  of  IT 
knowledge  within  the  organisation  become  evidently  critical.  Such  requirements  in 
effectively  engineering  IT  knowledge  demand  a  well-defined,  well-planned  and 
implementable  practice.  Architecture  Practice  can  be  such  a  practice  since  its 
fundamental  thinking  and  discipline  are  knowledge-based  or  knowledge-oriented. 
Whether  the  practice  of  managing  knowledge  can  be  successful  largely  depends  on 
what  kinds  of  architecture  capabilities  are  designed  and  achieved  in  association  with 
these  components. 


Figure  7-1 .  A  working  paradigm  of  IT  development  capability  (ITDC)  for  the  ADO 


In  such  a  paradigm,  five  components  working  together  to  deliver  the  required  IT 
development  capability  for  the  ADO  will  be  based  on  adequate  support  from  various 
architecture  capabilities. 
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It  is  certainly  true  that  architecture  itself  is  part  of  the  IT  development  capability. 
Without  proper  use  of  architecture  or  mature  architecture  practice,  the  IT  development 
capability  cannot  reach  a  satisfactory  level  for  large  organisations.  Architecture  can  be 
indeed  seen  as  a  starting  point  for  the  improvement  of  the  IT  development  capability. 

It  is  suggested  that  the  Senior  Defence  Executive,  such  as  the  DIEB  and  relevant 
agencies,  can  examine  which  and  how  capabilities  in  IT  development  or  future 
organisation  development  have  been  generated  and  how  mature  they  are. 

7.1  Enterprise  knowledge  centre 

An  enterprise  knowledge  centre  of  IT  products  requires  an  enterprise  architecture 
repository  to  capture  knowledge  regarding  all  existing  systems  within  the 
organisation.  This  covers  systems  knowledge  at  the  levels  of  operation,  function,  data, 
programming  platforms  and  networking,  and  also  what  needs  to  be  known  for 
developing  new  systems.  The  repository  should  include  an  important  element  which  is 
called  an  Enterprise  System  Architecture  or  Systems  Architecture  at  the  enterprise  level. 
This  element  is  currently  being  studied  by  a  joint  project  between  DSTO  and  Monash 
University,  and  will  be  the  main  resource  of  a  well  organised  and  integrated  systems 
knowledge.  This  knowledge  can  be  used  for  a  variety  of  reference  purposes  in  IT- 
related  R&D,  through  provision  of  multiple  views  of  systems. 

Such  a  repository  is  defined  and  described  in  the  recommend  architecture  practice,  and 
is  one  of  the  main  components  in  the  Architecture  Practice  Supporting  Environment 
(APSE). 

Knowledge  captured  in  the  repository  is  extracted  from  various  sources  of  systems 
knowledge,  such  as  system  development  documents  and  the  minds  of  system 
designers  and  developers.  The  extraction  of  knowledge  is  performed  through 
conducting  enterprise-wide  domain  engineering  or  a  similar  activity  with  adequate 
methodologies.  Thus,  such  knowledge  is  updated  and  maintained  as  a  living 
document. 

Developing  such  a  repository  contributes  directly  to  achieving  an  enterprise  level 
systems  architecture  description.  The  repository  is  a  critical  step  towards  maturing  the 
organisation's  ability  in  knowledge  management,  since  it  will  provide  a  means  to  stop 
the  loss  of  organisational  (systems)  knowledge. 

To  provide  the  enterprise  knowledge  centre  capability  architecture  capabilities  of 
knowledge  extraction,  publication  and  navigation — this  component  must  be  developed 
to  serve  as  a  key  measure  to  realise  knowledge  into  assets  of  the  organisation  and  make 
effective  reuse  possible. 

Apart  from  the  enterprise  system  architecture  that  is  an  "as-is"  architecture 
description,  the  enterprise  architecture  repository  may  also  include  other  resources  of 
knowledge  associated  with  systems  or  used  in  new  system  development. 


7.2  Research  and  development  for  future  capability 

The  IT  development  capabilities  within  component  include: 

•  Capability  &  Technology  Demonstration  (CTD)  development; 
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•  Enterprise  data  model  analysis  and  synthesis; 

•  Enterprise  information  flow  analysis; 

•  Information  operation  capability  study; 

•  Enterprise  interoperability  requirements  study; 

•  Studies  of  vendor-dependent  technology,  including  system  integration  solutions 
(such  as  WWW,  CORBA,  Lotus  Notes,  middleware,  messaging); 

•  Enterprise  or  joint  systems  behaviour  simulation  and  performance  evaluation;  and 

•  Enterprise  IT  capability  analysis. 


Architecture  products  in  various  forms  are  not  only  main  outcomes,  but  also  inputs  to 
these  areas.  Some  of  these  products  as  outcomes  are  passed  on  to  the  capabilities  of 
Enterprise  Planning  &  Business  Description  and  then  to  System  Development,  if  they 
are  approved  for  further  study  and  development. 

Studies  on  Information  Operations  (IO)  /  Electronic  Warfare  (EW)  could  also  be 
considered  under  this  capability. 

Remark 

No  specific  architecture  framework  has  been  developed  for  this  kind  of  IT 
development  capability  as  a  whole.  However,  a  unified  testbed,  such  as  EXC3ITE,  is 
important  since  it  can  deliver  CTDs  in  an  integrated  manner  and  with  better  efficiency 
and  effectiveness.  To  successfully  conduct  activities  in  these  areas,  EXC3ITE  needs  to 
develop  its  R&D-oriented  Architecture  Practice,  which  should  address  specific  needs  of 
R&D  and  form  as  part  of  the  Enterprise  Architecture  Practice. 

7.3  Enterprise  planning  and  business  description 

This  part  of  the  IT  development  capability  performs  plan  generation  and  requirement 
specifications  for  future  systems  development,  for  example  AST  and  DJFHQ 
development.  Using  architecture  products  or  capabilities  provided  by  other 
components  in  the  model,  planners  can  produce  planning  products,  some  of  which  can 
be  architecture  products,  at  both  strategic  and  operational  levels. 

The  architecture  capabilities  provided  to  this  area  include: 

•  Support  for  operational  architecture  generation 

Specific  military  operation  models  are  created  according  to  particular  requirements. 
This  framework  is  designed  to  enhance  both  conventional  organisation  planning 
processes  and  mission-oriented  strategic  level  planning. 

Senior  planning  officers  use  the  functions  provided  to  this  area  to  produce 
operational  architectures,  which  have  to  not  only  meet  business  requirements,  but 
.  also  be  based  on  the  availability  of  resources  and  the  existing  IT  capability  of  the 
organisation. 


Operational  architecture  development  is  a  specific  requirement  of  defence-business 
related  architecture  practice.  Most  architecture  frameworks  or  approaches 
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introduced  by  industry  players,  including  Zachman  and  MATE,  cannot  meet  this 
requirement. 

•  Guidance  for  determination  of  IT  capability 

Senior  IT  officers  need  to  work  with  the  planning  officers  in  determining  systems 
capability  and  information  flow  requirements  for  the  operational  architectures  by 
using  systems  knowledge  captured  in  the  enterprise  knowledge  repository  of  IT 
products. 

•  Guidelines  for  conceptual  construction  of  "Plug  and  Play  IT  functions 

Senior  IT  officers  produce  specifications  of  system  integration  according  to  the 
guidelines,  including  the  systems  information  exchange  matrix  and  systems 
function  traceability  matrix. 

To  support  the  warfighting  needs  of  AST  and  DJFHQ,  certain  specific  support  is 
required  to  dynamically  reconstruct  and  reconfigure  systems,  and  to  smooth 
systems  support  functions  and  information  flows. 

These  capabilities,  available  through  the  APSE,  can  assist  planning  officers  and  IT 
officers  to  complete  descriptions  of  operational  architectures  and  specifications  of 
required  IT  capability  in  accordance  with  architecture  construction  guidelines.  With 
these  architecture  capabilities,  the  processes  of  future  organisation  development  or 
reconstruction  can  be  formalised  to  a  certain  extent.  Architecture  products  produced  m 
this  area  do  not  represent  any  physical  systems  unless  they  can  be  implemented 
through  the  capability  of  system  development  and  under  the  IT  general  guidance. 

Through  using  these  architecture  capabilities,  we  can  ensure  that  IT  capabilities 
(including  "Plug  and  Play"),  which  support  core  businesses  such  as  warfighting,  can 
be  planned  successfully  in  a  joint,  global  environment  with  high  level  interoperability. 

7.4  System  development  and  General  IT  guidance 

Under  this  component  of  the  proposed  IT  development  capability,  the  ADO  requires 
the  architecture  capabilities  for  supporting  implementation,  including: 

•  Reference  architecture  for  system  integration  and  "plug  and  play"; 

•  Technical  architecture  framework  (such  as  the  US  DoD  JTA  or  META  Group 
EWTA); 

•  Framework/methodology  (such  as  the  C4ISR  AF)  for  developing  architectures  of 
new  systems; 

•  Architecture-based  methods  for  technology-dependent  solution  evaluation  and 
selection; 

•  Architecture-based  methods  for  system/ project  evaluation; 

•  Common  Operating  Environment  /  interoperability  matrices; 

•  Engineering  administration  and  project  control  framework;  and 

•  Standards  and  policy. 
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These  architecture  capabilities  work  together  through  the  APSE  discussed  in  Section  9 
to  form  the  IT-oriented  knowledge  management  environment  for  the  daily  business  of 
DISG,  DAO  and  other  IT  staff  of  the  Department,  and  assure  expected  IT  capabilities 
with  quality  and  efficiency. 

It  is  suggested  that  an  architecture-based  process  framework  for  system/project 
evaluation  be  developed  under  this  component,  since  it  can  assist  the  ADO  in 
systematically  analysing  interrelationships  and  connections  between  a  new  system  and 
other  existing  systems.  Clear  specifications  of  these  interrelationships  and  connections 
should  be  reached  before  implementation  commences.  In  the  absence  of  this,  many 
large  systems/projects  have  been  experiencing  various  difficulties  and  problems  in 
systems  integration  and  evolution. 

Note  that  decisions  made  now  and  in  the  future  in  selection  and  design  processes  of 
technology-dependent  solutions  (for  example,  choosing  a  distributed  computing 
platform,  such  as  Web,  DCE,  CORBA,  Java,  Lotus  Notes  or  Active  X,  for  systems 
integration)  are  much  more  complicated  and  difficult  than  selecting  a  DBMS,  OS  or  a 
programming  language  for  applications  development.  Thus,  a  comprehensive 
architecture  capability  is  highly  desirable  to  help  and  formalise  these  processes  and  to 
reduce  the  possibility  of  failures  caused  by  ignorance  of  some  important  factors. 

7.5  System  management  and  maintenance 

When  a  system  has  been  implemented,  integrated  and  introduced  into  service,  a 
framework  is  required  as  part  of  the  IT  development  capability  for  its  ongoing 
management,  to  ensure  that  it  continues  to  meet  requirements. 

The  capability  required  for  this  framework  can  be  divided  into  the  following  main 
areas,  which  also  require  the  use  of  architecture: 

•  Management  and  maintenance  of  current  IT  capability; 

•  Management  of  technology  changes; 

•  Management  of  user  and  business  changes; 

•  Managing  the  impact  of  system  of  systems  changes; 

•  Acquisition  of  systems  architecture  at  the  enterprise  level;  and 

•  Configuration  management,  including  dynamic  "plug  and  play"  management. 


The  first  of  these,  the  management  and  maintenance  of  current  IT  capability,  represents 
the  daily  activities  of  ensuring  that  the  IT  capability  in  service  continues  to  remain 
operational  and  effective.  The  rest  of  the  areas  are  concerned  with  the  understanding 
and  management  of  change. 

With  all  of  these  activities  it  is  very  important  that  the  existing  systems  knowledge 
from  all  the  other  components  of  the  IT  development  capability,  as  well  as  systems 
knowledge  gathered  within  this  framework  (i.e.  during  the  service  life  of  a  system),  is 
readily  available  in  a  useful  form.  Without  adequate  architecture  capabilities  to  ensure 
that  this  knowledge  is  maintained  as  an  organisational  asset,  activities  during  the 
service  life  of  a  system  are  at  best  conducted  inefficiently,  and  at  worst  lead  to  the 
severe  degradation  or  loss  of  the  IT  capability  that  was  supposed  to  be  provided. 
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7.6  Summary 

Using  the  philosophy  of  the  architecture  practice  suggested  earlier,  this  section  uses  a 
high  level  IT  development  capability  model  and  combines  it  with  the  recommended 
architecture  practice  model,  such  that  architecture  relevance  can  serve  as  a  basis  for 
integration  of  architecture  capabilities.  As  a  result  of  this  integration,  an  integrated 
architecture  capability  can  be  developed  with  the  support  of  an  enterprise  architecture 
practice  supporting  environment  (APSE). 

Such  an  Integrated  Architecture  capability  consists  of  the  following  components: 

•  Architecture  resources  that  include  various  architecture  products  both  descriptive 
and  supporting  developed  on  the  basis  of  a  well-established  architecture  lexicon, 

•  Architecture-based  functions /services,  including  generic  and  specific,  which  can 
realise  effective  use  of  architecture  for  various  purposes  in  all  aspects  of  future 
organisation  development; 

•  Well-defined  and  well-coordinated  architecture  development  processes  guided 
under  certain  methodologies; 

•  An  Architecture  Practice  Supporting  Environment,  as  discussed  in  Section  9,  which 
provides  not  only  solutions  for  architecture  resources  management,  but  also  a 
unified  and  integrated  platform  for  architecture-based  functions /services 
development. 

To  clarify  possible  confusion  in  the  relationship  between  such  an  IT  development 
capability  oriented  architecture  practice  philosophy  and  other  architecture  frameworks 
or  approaches,  it  is  worth  noting  the  following  points: 

1.  The  idea  of  using  the  IT  development  capability  in  combination  with  the 
recommended  architecture  practice  model  differs  from  use  of  a  particular 
methodology,  such  as  the  C4ISR  Architecture  Framework.  We  started  with 
identifying  the  IT  development  capabilities  required  by  the  ADO,  in  particular  in 
supporting  evolutionary  development  of  C3I  systems.  This  shows  specific 
requirements  of  architecture  for  the  ADO,  which  are  much  broader  than  what 
existing  architecture  frameworks  can  cover  individually. 

This  idea  does  not,  however,  reject  use  of  those  frameworks  or  approaches  if  they 
are  proved  to  fit  well  into  the  paradigm  and  the  ADO's  needs.  Indeed,  it  helps  us  to 
effectively  use  them  and  to  further  develop  or  mature  them  within  the  context  of 
the  IT  development  capability  for  the  ADO. 

2.  The  analysis  of  ADO  IT  development  capability  shows  the  importance  of  using  an 
architecture  knowledge  value  chain  for  the  architecture  practice  that  can  provide  a 
context  or  framework  of  use  of  multiple  architecture  frameworks  or  approaches 
within  the  organisation.  In  other  words,  it  helps  us  to  relate  different  architecture 
frameworks  that  cover  different  aspects  in  architecture  practice. 

3.  The  paradigm  suggested  here  is  just  a  starting  point  of  a  long-term  effort  to  mature 
the  organisation's  IT  development  capability  through  using  architecture.  Decisions 
as  to  whether  the  ADO  should  adopt  such  a  paradigm  must  be  made  by  an 
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authorised  agency,  such  as  the  DIEB,  and  endorsed  at  a  high  level.  Planning  and 
coordination  of  development  of  architecture  capabilities  requires  a  dedicated 
working  group  with  representatives  from  relevant  parties  within  the  organisation, 
which  is  similar  to  the  C4ISR  Architecture  Working  Group  (AWG)  that  produced 
the  C4ISR  architecture  framework  for  US  DoD. 


4.  This  paradigm  suggests  that  a  unified  top-down  framework  be  used  for  planning 
the  IT  development  capability.  The  advantages  of  using  this  framework  are  to: 

•  Define  a  fundamental  business  model  of  IT  practice,  including  architecture  practice, 
for  the  organisation; 

•  Achieve  effective  architecture  practice  management; 

•  Clearly  identify  weaknesses  or  gaps  in  the  IT  development  capability; 

•  Enable  R&D  activities  to  be  carried  out  in  a  well-planned  development  context; 

•  Facilitate  flexibility  in  selection  of  methodologies  and  change  or  evolution  of 
concepts  and  technology; 

•  Enable  individual  concepts,  techniques  and  systems  to  evolve  smoothly  and 
consistently  with  other  relevant  components;  and 

•  Provide  senior  officers  with  a  better  understanding  of  the  business  of  the  DIE  and 
adequate  support  in  planning  and  reviewing  projects. 
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8.  Chief  Infonnation  Architect  (CIA)  and  Architecture 

Review  Board  (ARB) 

With  the  understanding  of  the  relationship  between  the  IT  development  capability  and 
architecture  practice  discussed  in  the  previous  section,  this  section  discusses  how  the 
expected  architecture  practice  can  be  planned  and  implemented  within  the  ADO  by  the 
CIA  and  the  ARB. 

8.1  Main  interests  of  CIA  and  ARB 

Planning  and  managing  architecture  practice  is  the  key  business  of  the  Chief 
Information  Architect  and  the  Architecture  Review  Board  that  was  formed  under  the 
recommendations  of  the  DIEB. 

In  practice,  there  are  many  teams  working  in  different  areas  on  the  development  of 
individual  architecture  products.  In  order  to  manage  enterprise-wide  architecture 
practice,  the  CIA  and  ARB  should  oversee  what  architecture  products  have  been  or 
will  be  developed,  through  which  processes  and  using  which  methodologies,  and  how 
they  are  maintained  and  used  over  time. 

Thus,  it  should  be  the  responsibility  of  the  CIA  and  ARB  to  develop  and  manage  a 
business  model  of  the  enterprise-wide  architecture  practice,  to  make  decisions  on  the 
generation  of  architecture  capabilities  and  review  outcomes,  and  to  make  sure  that 
their  integration  can  be  achieved.  Figure  8-1  expresses  the  three  aspects  of  the 
architecture  practice  that  the  CIA  and  ARB  must  control. 

The  ADO  has  developed  architectures  and  therefore  had  a  form  of  architecture 
practice.  This  will  continue  even  without  guidance  from  the  CIA  and  the  ARB.  The 
difference  that  the  CIA  and  the  ARB  can  make  to  the  future  architecture  development 
is  a  disciplined  architecture  practice  with  a  distinctive  outcome  of  an  integrated 
architecture  capability. 

8.2  Main  activities  under  the  CIA  and  ARB 

Since  the  ARB  was  formed,  there  have  been  many  reports  on  the  ongoing  progress  of 
various  activities  made  at  its  monthly  meetings.  To  the  authors  understanding,  the 
main  progress  in  the  development  of  architecture  products  within  the  ADO  can  be 
classified  into  four  main  subsets  at  the  enterprise  level  as  shown  in  Figure  8-2,  namely. 
Operational  Architecture  subset,  Systems  Architecture  subset,  Technical  Architecture  subset 
and  Concept  Technology  Demonstrators  (CTDs). 

The  main  purposes  for  grouping  various  architecture  products  and  capabilities 
developed  within  the  ADO  into  these  four  subsets  are:  1)  to  create  a  framework  for 
architecture  product  management  at  the  enterprise  level;  2)  to  present  all  relevant 
products  in  a  context  that  can  be  used  to  compare  various  architectural  approaches  or 
enterprise  architecture  frameworks  (such  as  the  C4ISR  AF  and  Meta  Group  EWTA  or 
EAS);  and  3)  to  see  precisely  how  architectures  can  be  related  to  each  other  when 
architecture  production  processes  are  introduced. 
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Architecture-based  capabilities  supporting 
future  organisation  development 


Figure  8-1.  Aspects  the  CIA  and  ARB  must  control  in  architecture  practice. 


All  supporting/ guiding  architecture  products  developed  in  these  subsets  can  be  seen 
as  the  enterprise  supporting  elements  of  the  ADO  APSE. 

Each  of  these  subsets  should  include  a  number  of  defined  elements  that  play  different 
roles  in  future  architecture  development.  If  necessary,  certain  architecture  frameworks 
or  approaches  can  be  used  to  guide  the  development  of  these  subsets.  For  example,  the 
approach  used  in  developing  TAFIM  by  US  DoD  or  EWTA  by  META  Group  can  be 
used  to  guide  development  of  the  Technical  Architecture  subset. 

Developing  the  operational  architecture  subset  is  a  critical  task  and  one  that  is  not 
familiar  to  both  defence  and  IT  communities.  This  subset  will  include  a  number  of 
architecture  products,  such  as  Task  Lists,  Military  Response  Options,  Business 
/Operational  (day-to-day)  architectures  of  the  Services  and  campaign  planning 
guidelines.  These  products  are  used  in  operation  planning  for  either  the  joint  or  single 
service;  and  play  supporting  roles  in  developing  future  operational  architectures  at  all 
levels  for  various  mission-oriented  purposes. 

It  is  noted  that  in  order  to  realise  the  value  of  architecture,  the  development  of 
architecture  products  in  these  subsets  should  not  be  isolated  from  their  application 
processes.  Without  knowing  how  they  can  be  used  and  planning  to  implement  that,  the 
value  and  significance  of  architecture  would  be  dramatically  reduced.  Ill-planned 
development  of  architecture  products  in  any  of  these  subsets  may  not  only  cause 
confusion,  but  also  generate  products  that  may  not  be  able  to  be  used  effectively. 
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Figure  8-2.  An  integrated  architecture  capability. 

8.3  Main  views  for  managing  architecture  practice 

Three  main  views  are  suggested  to  assist  the  CIA  and  the  ARB  in  managing  the 

architecture  practice  of  the  ADO,  with  these  being.  Architecture  Products  View, 

Process/Methodology  View  and  Tools/Environment  View. 

•  Architecture  Product  View  defines  which  sets  of  architecture  products  should  be 
developed  and  clarifies  use  of  terminology. 

•  Process/Methodology  View  addresses  how  those  products  should  be  developed 
through  which  processes  and  methodologies. 

•  Tool/Environment  View  provides  solutions  and  support  for  physical  development 
and  management  of  architecture  products  over  time,  and  realisation  and 
integration  of  architecture-based  capabilities. 


Through  use  of  the  three  views,  the  CIA  and  ARB  can  see  any  architecture  product  or 
architectural  framework  as  an  element  in  the  whole  practice  and  have  the  ability  to 
deal  with  the  complexity  of  multiple  frameworks  based  practice,  as  discussed  in  a 
subsequent  section.  Note  that  without  a  broad  and  deep  understanding  of  architecture 
issues,  it  can  easily  be  believed  that  developing  a  certain  architecture  product(s),  often 
called  the  enterprise  architecture(s),  could  solve  all  issues  in  architecture  for  the  ADO. 
Such  a  belief  could  become  a  barrier  that  restricts  the  organisation  from  looking  at 
much  broader  architecture  issues  for  achieving  the  full  benefits  of  architecture  practice. 
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Therefore,  the  architecture  practice  thinking  is  one  level  above  most  existing 
architecture  frameworks  or  approaches.  This  is  why  the  well-planned  and  well- 
organised  architecture  practice  can  accommodate  multiple  architecture  frameworks  if 
necessary. 

Remark:  The  main  advantages  of  using  this  three- view-based  management  strategy 
are:  1)  reducing  confusion  in  use  of  different  terminologies;  2)  providing  clear  context 
management  of  the  practice  in  an  inclusive  manner;  3)  being  able  to  accommodate 
multiple  frameworks  for  different  architecture  production  (as  discussed  in  Section  10); 
and  4)  a  focus  on  improved  general  IT  development  capability  rather  than 
development  of  any  single  product. 

A  management  framework  for  ADO  architecture  practice  can  be  defined  on  the  basis  of 
these  three  views. 

8.4  Survey  of  ADO  architecture  products 

As  an  important  representation  of  system  knowledge,  as  discussed  in  the  Part  1  of  the 
report,  architecture  is  a  concept  that  has  six  main  attributes  determining  its  context  in 
multiple  dimensions,  as  shown  in  Figure  8-3.  It  is  these  attributes  that  create 
complicated  relationships  amongst  various  architectures  (products).  Therefore,  to  fully 
understand  the  context  of  an  architecture  product,  including  its  roles,  relations  to 
others  and  ways  to  use  it,  the  clarification  of  these  attributes  for  each  architecture 
product  is  important. 

As  part  of  the  architecture  practice  study,  DSTO  intends  to  conduct  a  survey  of 
architecture  products  in  the  ADO.  Such  a  survey  will  help  gain  an  understanding 
about  the  current  state  of  architecture  practice  across  the  organisation.  It  is  also  an 
important  step  towards  establishment  of  coordinated  architecture  data  management 
across  the  organisation,  and  will  provide  a  basis  for  effective  evaluation  and 
rationalisation  of  architecture  practice. 

The  aim  of  the  survey  is  to  capture  information  about  architecture  products  in  a 
methodology-neutral  manner.  No  strict  definition  of  architecture  will  be  suggested  by 
the  survey,  although  some  explanation  of  certain  terms  will  be  necessary.  The  survey 
will  be  designed  to  capture  important  attributes  of  architecture  products  and 
architecture  related  products. 

The  survey  will  initially  be  conducted  in  a  limited  fashion  with  a  narrow  scope,  before 
it  is  more  widely  conducted  across  the  organisation. 

It  is  expected  that  the  survey  will  provide  information  about  what  architecture 
products  have  been  developed  or  planned,  what  roles  each  architecture  product  plays, 
and  how  the  architecture  products  have  been  used,  as  well  as  what  methods  and  tools 
have  been  used  in  their  development.  Other  information  useful  for  architecture 
product  management  will  also  be  collected. 
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Figure  8-3.  Architecture  attributes  in  multiple  dimensions. 
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9.  Architecture  Practice  Supporting  Environment  for 

the  ADO 

9.1  What  is  it  going  to  achieve? 

In  the  recommended  architecture  practice  discussed  in  Part  1  of  the  Phase  I  report,  the 
architecture  practice  supporting  environment  (APSE)  is  one  of  the  key  components 
defined.  It  is  through  this  component  that  various  architecture-based  capabilities  can 
be  broadly  presented  in  an  integrated  manner  to  a  wide  community  for  knowledge 
sharing  and  reuse  and  supporting  future  organisation  development.  It  is  through  this 
component  that  the  CIA  and  ARB  can  successfully  manage  the  architecture  practice 
and  bring  healthy  cultural  changes  to  Defence  through  creating  a  workable 
architecture  environment. 

9.2  Design  Principles  of  the  APSE 

Development  of  the  APSE  is  a  key  to  achieving  an  integrated  architecture-based 
capability  for  the  ADO  as  a  whole.  While  capabilities  associated  with  various 
architecture  products  have  been  developed,  an  integrated  APSE  is  yet  to  be  addressed. 
The  development  of  this  capability  should  be  seen  as  one  of  the  main  tasks  of  the 
Architecture  Review  Board  or  related  architecture  working  groups  of  the  Department. 
The  design  principles  of  the  APSE  for  the  ADO  can  be  discussed  in  the  following  main 
aspects. 

•  Requirements  studies.  The  working  paradigm  of  IT  development  capability 
shown  in  Figure  7-1  can  be  used  as  the  starting  point  to  study  requirements  for  this 
environment.  Various  use  scenarios  and  potential  architecture-based  capabilities  to 
be  developed  can  help  outline  both  generic  and  specific  functions/capabilities  of 
the  APSE. 

•  Composition.  The  requirements  studies  can  help  determine  which  elements 
should  be  included  in  the  environment. 

•  Relation  to  existing  tools  and  capabilities.  Since  the  APSE  will  serve  as  a 
unified  platform  for  generation,  management,  evolution  and  use  of  architecture, 
integration  of  the  APSE  and  the  tools  used  in  architecture  development  and 
architecture  repository  management  are  two  main  issues  that  need  to  be  addressed 
when  the  APSE  is  developed. 

•  Architecture  management.  Solutions  for  enterprise-wide  architecture 
products/data  management  should  be  designed  and  implemented  through 
development  of  the  APSE.  There  are  two  areas  where  adequate  solutions  must  be 
addressed:  1)  corporate  supporting  architecture  product  or  ESE  management;  and 
2)  systems  architecture  at  the  enterprise  level,  also  called  enterprise  system 
architecture. 


More  detailed  investigation  into  the  design  issues  of  the  APSE  will  be  addressed  in  a 
separate  report  of  the  Architecture  Practice  Study. 
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9.3  APSE  development  by  the  US  DoD 

When  the  C4ISR  Architecture  Framework  was  introduced,  a  number  of  reference 
elements  or  common  building  blocks  (JTA,  JOA,  LISI,  CADM,  SHADE,  UJTL,  TRM  and 
DDDS)  were  mentioned  as  supporting  references.  These  formed  an  initial  set  of  the 
enterprise  supporting  elements  for  the  architecture  practice  of  the  US  DoD.  Indeed, 
any  other  architecture  approaches  or  frameworks,  or  architecture-related  activities 
should  also  be  able  to  use  them. 

Though  US  DoD  has  not  yet  formally  identified  any  systems  developed  in  association 
with  its  architecture  practice  as  its  architecture  practice  supporting  environment 
(APSE),  the  development  of  the  Joint  C4ISR  Architecture  Planning/ Analysis  System 
(JCAPS)  under  the  C4ISR  Architecture  Working  Group  of  OASD  (C3I)  is  an  indication 
that  the  US  DoD  intends  to  have  its  architecture-based  capabilities  integrated,  and  to 
deliver  them  to  various  users  across  broad  areas  of  the  US  DoD. 

9.4  ADO'S  APSE 

The  main  purpose  of  pursuing  architecture  practice  for  the  ADO  is  to  improve  IT 
development  capability  across  the  organisation  as  an  integrated  whole.  It  is  intended 
that  this  will  be  realised  by  achieving  a  high-level  knowledge  practice  through 
engineering  IT  systems  knowledge  and  integrating  it  with  warfighting  business 
knowledge.  The  capability  is  by  its  nature  provided  by  the  coordinated  efforts  of  often 
traditionally  disparate  parts  of  the  organisation,  which  together  comprise  all  the 
related  areas  where  the  various  architecture  activities  occur.  This  generates  a  diversity 
of  architecture  products  or  supporting  products  as  architecture  knowledge  resources. 
The  accessibility  of  these  products  is  important  and  is  one  of  the  key  factors  that 
determines  the  level  of  architecture  practice  maturity.  Successful  use  of  these  products 
realises  their  value.  To  achieve  these  aims  the  practice  needs  to  cover  the  whole 
spectrum  from  resource  generation  through  to  service  provision  within  the  practice 
community. 

As  discussed  in  Part  1,  the  solution  for  effective  management  and  use  of  architecture 
knowledge  resources  is  to  develop  an  Architecture  Practice  Supporting  Environment 
for  the  ADO. 

Figure  9-1  shows  the  recommended  APSE  for  the  ADO,  which  includes  three  main 
sectors,  namely,  architecture  resources,  shared  facilities  and  architecture  services. 

•  Architecture  resources  are  a  collection  of  developed  architectures  including  both 
supporting/ guiding  and  descriptive  products  that  can  be  used  across  the 
organisation.  Building  up  the  architecture  resources  is  the  responsibility  of  all 
relevant  parties. 

•  Shared  facilities  are  all  necessary  functions  to  generate,  manage  and  use 
architectures,  including  those  supports  necessary  for  enterprise-wide  architecture 
knowledge  sharing,  such  as  repository  and  web-based  access. 

•  Architecture  services  are  those  architecture  capabilities,  based  on  the  shared 
facilities,  developed  specifically  for  different  business  domains. 

In  a  disciplined  and  well-organised  architecture  practice,  architecture  capabilities 
development  for  different  purposes,  such  architecture-based  simulation,  modelling. 
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planning  and  evaluation,  can  greatly  benefit  from  developed  and  available  architecture 
resources  and  shared  facilities  and  can  be  carried  out  in  an  integrated  manner. 
Consequently,  these  capabilities  can  be  more  practically  and  efficiently  used  by 
relevant  parties  /  developers  or  users  of  APSE  in  supporting  improvement  of  ADO's 
ITCD. 
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Figure  9-1.  The  recommended  APSE  for  the  ADO. 

9.5  ADO's  systems  architecture  —  a  hole  to  be  filled 

Most  architectures  of  individual  systems  are  developed  at  a  project  level  by  different 
teams  using  different  methodologies.  It  has  been  difficult  to  see  the  architecture  of 
systems  of  systems  or  systems  architecture  at  the  enterprise  level.  If  an  enterprise  needs 
to  be  seen  as  a  "big"  system,  there  are  unsolved  questions  regarding  its  enterprise, 
system  architecture:  1)  do  we  need  this  architecture;  2)  which  role  (blueprint  or  current 
picture)  this  architecture  plays;  3)  when  the  architecture  should  and  can  be  developed; 
4)  whether  it  is  updated;  5)  who  is  responsible  for  development  and  maintenance  of 
such  an  architecture. 

As  discussed  in  Part  1  of  this  report,  developing  systems  architecture  at  the  enterprise 
level  is  important  for  evolutionary  acquisition  of  SOS,  but  challenging  because  there 
has  been  no  existing  solution  and  no  one  has  taken  responsibility  for  it.  This  is  a 
similar  task  to  the  development  of  JSA  in  the  US  DoD.  The  Architecture  Practice  Study 
task  suggests  that  such  an  systems  architecture  be  developed  as  part  of  an  architecture 
repository,  and  has  started  a  joint  research  project  with  Monash  University  to  address: 

•  A  study,  including  literature  reviews  and  theoretical  findings,  of  the  concept  of  an 
enterprise  systems  architecture  repository  combined  with  the  real  world  practice  of 
the  ADO; 

•  Principles  of  engineering  and  using  information  systems  architecture  knowledge; 
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•  A  framework  of  design  for  a  repository  that  meets  the  requirements  in  knowledge 
representation  and  management  functions  required;  and 

•  Notations  or  descriptive  languages  used  in  deriving,  refining  and  integrating 
systems  architecture  knowledge  and  maintaining  it  in  a  repository. 

Research  issues  that  need  to  be  addressed  fall  mainly  in  two  related  sectors. 

1.  Requirements  study 

To  study  requirements  for  an  architecture  repository,  the  project  will  investigate 
the  following  aspects: 

•  Which  information  systems  knowledge  should  be  captured; 

•  What  purposes  the  knowledge  is  used  for; 

•  What  functions  an  architecture  repository  should  be  provided  with  and  in  what 
application  scenarios;  and 

•  How  the  architecture  repository  is  related  to  other  elements  defined  in  the 
architecture  practice  supporting  environment. 

2.  Design  issues 

To  work  towards  designing  such  a  repository,  the  project  will  have  research 
focuses  on  certain  technical  concerns  and  their  theoretical  underpinning,  including: 

•  A  framework  or  organisation  structure  for  the  repository; 

•  Proper  notations  or  descriptive  languages  used  to  capture  and  interrelate  systems 
architecture  knowledge  for  storage  in  the  repository; 

•  Management  of  architecture  views  to  assure  sufficient  functions  and  flexibility  for 
use  of  the  knowledge; 

•  Ability  to  support  architecture  analysis  through  use  of  the  repository;  and 

•  Relation  to  and  integration  with  Computer  Aided  Software  Engineering  (CASE) 
tools. 

The  progress  of  the  ADO's  systems  architecture  will  be  reported  separately. 
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10.  Multiple  Frameworks  Based  Practice 

As  discussed  in  previous  sections,  a  total  solution  for  the  ADO  enterprise-wide 
architecture  practice  can  be  studied  through  using  the  concepts  of  architecture  practice 
and  IT  development  capability. 

Distinguishing  this  total  solution  from  the  concept  of  the  enterprise  architecture  is 
important.  It  was  pointed  out  earlier  that  the  enterprise  architecture  suggested  by 
many  architectural  approaches  is  only  part  of  the  total  solution.  It  is  an  important  one 
but  it  must  be  clearly  defined  in  terms  of  the  roles  (a  descriptive  product  or  a 
supporting  product)  it  can  play  in  the  whole  architecture  practice. 

10.1  Using  the  term  "Enterprise  Architecture"  with  caution 

The  term  "Enterprise  Architecture"  has  been  used  in  different  contexts  by  many  teams 
and  projects  within  the  ADO,  which  are  mainly  associated  with  the  use  of  different 
methodologies  or  in  the  discussion  of  certain  ADO  documents.  These  include: 

•  Use  associated  with  the  Zachman  Framework 

•  Use  associated  with  the  META  Group's  EAS  and  EWTA 

•  Use  associated  with  the  C4ISR  AF 

•  Use  associated  with  RM-ODP 

•  Use  associated  with  the  DIE  Architecture  Framework 

•  Use  associated  with  specific  sub-domains  of  the  ADO 


According  to  these  different  uses  of  the  concept,  we  see  the  so-called  enterprise 
architecture  as  one  of  the  following  products: 

•  One  or  a  set  of  architectures,  such  as  a  standard-based  Technical  Architecture, 
which  play  mainly  supporting  or  guiding  roles  for  enterprise  wide  IT  practice; 

•  An  architecture  description  of  the  enterprise,  which  can  be  either  "as-is"  or  "to-be"; 
or 

•  A  technology-dependent  enterprise  design  solution. 


Strategically,  therefore,  the  ADO  needs  to  first  decide  its  own  definition  of  enterprise 
architecture.  If  its  definition  is  consistent  with  any  use  in  the  above  cases,  this 
architecture  should  then  be  treated  as  a  single  product  or  a  set  of  elements  within  the 
enterprise  architecture  practice. 

Whether  a  specific  area  or  part  of  the  ADO  can  be  seen  as  an  enterprise  is  a  debatable 
issue.  It  is  important,  however,  to  make  the  context  clear  when  the  term,  "enterprise 
architecture",  is  used. 


Remark 

A  total  enterprise  architecture  solution  for  the  ADO  should  therefore  have  the 
following  features: 
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•  Dealing  with  the  result  of  evolutionary  development  of  systems  of  systems  (SOS); 

•  Providing  an  understanding  of  SOS  rather  than  a  single  design  solution, 

•  Generating  an  evolving  and  valuable  asset  of  the  organisation  knowledge,  in 
particular  C4ISR  operations  knowledge; 

•  Developing  a  set  of  principles  and  guidelines  for  future  system  architecture 
development; 

•  Defining  a  set  of  processes  for  architecture  production,  management  and  evolution; 

•  Developing  a  knowledge  environment  for  improved  systems  knowledge 
communications;  and 

•  Developing  a  supporting  environment,  APSE,  for  the  formation  of  an  integrated 
architecture  capability. 

The  relationship  between  the  enterprise  architecture  as  suggested  by  either  META 
Group  or  the  Zachman's  Framework  and  the  architecture  practice  philosophy  is 
discussed  in  Part  1  of  this  report.  It  is  worthwhile  to  recall  here  that  the  enterprise 
architecture  should  be  one  of  the  important  elements  in  the  architecture  practice  and  it 
cannot  achieve  the  full  potential  of  the  architecture  practice  without  integration  with 
other  architecture-related  activities.  Suitability  of  an  architectural  approach  for  a 
specific  organisation  must  be  properly  examined  before  use. 

10.2  Evaluation  and  selection  of  architecture  frameworks 

It  is  strongly  suggested  that  any  important  architecture  development  should  follow 
certain  guidance  in  an  architecture  framework  or  methodology.  The  ADO's 
architecture  practice  requires  guidance  for  its  three  main  subsets,  namely.  Operational 
Architecture  subset.  Systems  Architecture  subset  and  Technical  Architecture  subset. 

After  familiarisation  with  various  architecture  frameworks,  the  ARB  needs  to  make 
decisions  on  which  frameworks  should  be  used  for  development  of  which 
architectures. 

Since  it  is  not  an  easy  task,  developing  a  new  framework  for  specific  needs  in  certain 
areas  of  the  ADO  is  necessary  only  if  no  existing  framework  is  suitable.  Risks  involved 
in  such  development  can  be  reduced  if  a  solid  understanding  of  the  existing  and  whole 
context  of  the  architecture  practice  can  be  reached. 


ADO's  broad  interests  in  architecture  require  an  architecture  practice  thinking  based 
on  multiple  architecture  frameworks.  Multiple  architecture  frameworks  can  be  jointly 
used  in  different  areas  of  the  ADO's  practice  and  can  be  beneficial  to  each  other  if  the 
practice  is  well  planned  and  well  coordinated. 

An  important  issue  in  multiple-framework  based  practice  coordination  is  the  planning 
and  selection  of  an  appropriate  set  of  enterprise-wide  supporting  elements.  These  can 
be  either  be  defined  in  an  architecture  framework  used  or  developed  independently  as 
far  as  they  can  play  the  necessary  supporting/ guiding  roles  in  a  complementary 
manner  in  future  architecture  development.  For  example,  some  supporting  elements, 
which  are  similar  to  the  common  reference  blocks  of  the  C4ISR  AF,  and  certain  domain 
architectures  suggested  by  META  EAS  can  all  be  chosen  as  the  enterprise-wide 
supporting  elements  if  the  ADO  decides  to  use  both  approaches. 
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11.  Architecture  Product  Planning  and  Management 

11.1  Architecture  product  planning 

Because  of  their  diversity  and  multiple-dimensional  attributes,  values  of  different 
architecture  products  vary  and  change  over  time.  One  of  the  main  principles  of 
architecture  practice  is  to  optimise  architecture  production  and  maximise  the  value  of 
developed  architectures. 

Apart  from  the  six  main  attributes  of  each  architecture  that  create  the  high  complexity 
of  architecture  practice  (as  discussed  earlier),  it  is  observed  by  the  architecture  practice 
study  that  underperformance  or  failure  in  architecture  development  is  often  caused  by 
the  following  factors: 

•  Over-estimating  the  value  of  a  specific  architecture  product; 

•  Insufficient  use  of  developed  architectures; 

•  Short  lifecycle  of  an  architecture  product,  in  particular  for  those  future  architectures 
if  they  are  technology  dependent; 

•  Ill-defined  context  of  the  architecture  business  cycle  (ABC)  for  a  specific 
architecture  from  its  definition,  view  type,  roles  and  development  method  to  use; 

•  Lack  of  coordination  among  relevant  architecture  activities  and  integration  of  ABCs 
of  relevant  architecture  products;  and 

•  Inappropriate  decision  making  in  architecture,  which  largely  depends  on  personal 
understanding  and  preference  of  individual  developers,  rather  than  being 
examined  and  approved  by  authorised  agencies. 


In  order  to  improve  the  performance  of  architecture  practice,  therefore,  it  is  necessary 
to  establish  the  formal  process  of  architecture  product  planning.  Without  this  planning, 
effective  architecture  product  management  cannot  be  carried  out,  and  the  success  of 
the  whole  architecture  practice  will  be  compromised. 

Successful  architecture  product  planning  relies  on  the  establishment  of  a  consistent 
architecture  value  system  across  the  organisation  to  clarify  the  context  and  value  of 
architecture. 

11.2  System  knowledge  generation  and  management 

Knowledge  issues  in  IT  practice  are  complicated  and  demand  better  solutions.  The 
proposed  ADO  APSE  has  the  potential  to  become  a  knowledge  management 
environment  for  architecture  practice,  which  could  help  the  organisation  to 
significantly  improve  production,  use  and  management  of  system  knowledge  in  IT 
practice. 

To  support  the  re-use  of  knowledge,  therefore,  the  recommended  architecture  practice 
shown  in  Figure  5-2  has  the  following  features: 
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•  Consideration  of  all  R&D  activities  as  in  a  whole  process  which  needs  internal 
coordination  to  transform  knowledge  (various  architecture)  products  and  preserve 
them  over  time; 

•  Separating  acquisition  of  SOS  architecture  (of  existing  systems)  or  systems 
architecture  from  conventional  design  process  and  making  it  an  independent  task 
that  obtains  and  maintains  the  IT  knowledge  in  the  repository; 

•  Taking  the  viewpoint  of  product  management  in  architecture  practice,  architecture 
production  plans  need  to  be  made  against  the  three  subsets  accordingly  in  order  to 
ensure  they  can  be  covered  when  related  processes  are  defined  and  developed. 

11.3  Coordination  of  architecture  issues 

11.3.1  Framework  coordination 

US  DoD's  experience  in  architecture  (USGAO,  1998)  shows  that  coordination  among 
concepts,  products,  methodologies  and  working  groups  is  an  extremely  difficult  and 
continuous  task.  This  is  because  all  these  aspects  are  changing  and  evolving  in  parallel 
over  time.  An  overall  control  mechanism  is  very  desirable,  but  difficult  to  achieve. 

Architecture  framework  coordination  is  not  seen  as  an  internal  issue  of  any 
architecture  framework,  but  is  definitely  an  issue  for  the  architecture  practice,  in 
particular  when  it  is  a  multi-framework  based  practice.  The  main  objectives  of  the 
coordination  are: 

•  Smoothness  in  system  knowledge  generation  and  management  processes 

•  Representation  consistency  in  terminology  and  graphical  presentation 

•  Knowledge  communication  support 

•  Accessibility  to  architecture  products 

•  Traceability  of  architecture  production 

•  Completeness  of  systems  knowledge 

•  Product  transformation  support 

11.3.2  Architecture  Business  Cycle  (ABC)  coordinatioii  and  management 

Effective  use  and  reuse  of  architecture  products  demands  not  only  accessibility  to  the 
products,  but  also  their  evolutionary  and  extendable  ABCs.  Each  architecture  product 
has  its  own  ABC.  The  Integrated  architecture  product  cycle  illustrated  in  Figure  5-2 
forms  an  architecture  knowledge  value  chain  and  shows  how  individual  ABCs  of 
architecture  products  depend  on  each  other  and  how  knowledge  value  can  be  realised 
and  preserved  in  practice. 

Effective  planning  and  management  for  supporting  products  are  extremely  important 
measures  to  ensure  a  well  defined  and  organised  overall  architecture-based  approach 
for  future  system  development  within  tire  ADO. 

From  the  experience  of  US  DoD  it  is  observed  that  such  an  approach  is  not  well 
defined,  since  its  supporting  elements  have  not  been  fully  developed  and  a  unified 
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supporting  environment  is  yet  to  be  developed.  Without  the  coordination,  and  due  to 
lack  of  understanding  of  architecture  practice,  the  products  are  mainly  developed 
based  on  the  understandings  and  preferences  of  individuals.  In  other  words,  there  is 
no  guarantee  that  the  product  could  fit  together  well  when  the  practice  becomes  more 
mature.  Consequently,  dramatic  changes  or  even  redesign  may  become  necessary 
during  the  course  of  evolution. 

Therefore,  a  lot  of  difficulties  and  challenges  have  resulted  from  a  lack  of  coordination 
when  the  products  are  developed.  In  the  current  practice  of  the  ADO,  most  of  its 
products  have  not  yet  been  developed.  Thus,  effective  architecture  product 
management  and  coordination  across  those  subsets  should  be  considered  and 
organised  to  decide  which  supporting  or  descriptive  products  are  needed  and  how 
they  should  be  developed. 
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12.  Implementation  strategies 

Architecture  practice  is  an  ongoing  effort  of  the  organisation  based  on  various  activities 
across  the  whole  organisation.  This  section  briefly  describes  the  relevance  and 
responsibilities  of  the  main  areas  of  the  ADO  which  have  important  roles  to  play  in 
architecture  practice. 

12.1  Capability  Development 

The  planning  of  the  ADO’s  architecture  practice  is  best  performed  by  those  responsible 
for  Capability  Development  for  the  following  reasons: 

•  Information-based  capability  is  part  of  the  defence  capability  for  knowledge 
warfare  and  is  a  key  to  success.  An  inability  to  efficiently  and  cost-effectively 
deliver  an  advanced  information-based  capability  for  the  ADF  is  challenging  tire 
organisation's  capability  in  its  future  development. 

•  Planning  and  improving  the  IT  development  capability  for  the  ADO  to  better 
operate  its  IT  business  and  improve  the  capability  of  future  organisation 
development  is  a  task  of  Capability  Development,  although  it  is  not  a  traditional 
one. 


In  order  to  plan  and  start  enterprise-wide  architecture  practice  within  the  ADO, 
strategic  decisions  for  the  whole  organisation  need  to  be  made.  Capability 
Development  has  the  responsibility  for  making  these  decisions  on  the  organisation's 
behalf  in  the  following  areas: 

•  Strategic  directions  and  scope  of  architecture  practice 

•  Business  model  of  the  architecture  practice 

•  Organisation  structures  of  the  practice 

•  Management  and  coordination  of  architecture-related  activities 

•  Prioritising  initiatives  and  evaluating  the  existing  practice 

•  Making  other  relevant  parties  aware  of  their  responsibilities  in  architecture  practice 


It  is  suggested  that  Capability  Development  and  the  DIEB  should  have  architecture 
practice  thinking  at  a  level  that  is  above  developing  individual  architecture  products  or 
capabilities.  Its  main  objective  is  to  make  sure  these  individual  products  and 
capabilities  can  be  integrated  and  form  a  unified  architecture-based  knowledge 
platform  to  support  future  organisation  development. 

12.2  Defence  Materiel  Organisation  (DMO) 

The  defence  information-based  capabilities  used  in  operations  are  predominantly 
developed  by  industry  and  acquired  through  the  DMO.  The  history  of  the  acquisition 
process  of  many  software-intensive  systems  has  shown  that  there  are  great  challenges 
for  the  ADO,  and  in  particular  the  DMO.  The  issue  is  how  to  efficiently  and  cost- 
effectively  produce  advanced  information-based  capabilities  with  high-level 
interoperability  through  applying  the  latest  technologies. 
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Enterprise  wide  architecture  practice  can  help  the  DMO  in  process  innovation  and 
cultural  change  of  the  acquisition  process  through  improved  knowledge  acquisition 
capability  in  all  stages  of  the  development  and  delivery  of  a  system.  This  includes  the 
following: 

•  Tire  inclusion  of  knowledge  or  architecture  acquisition  in  the  acquisition  process; 

•  Making  industry  contractors  aware  of  the  ADO's  architecture  practice  and 
requiring  them  to  follow  it  accordingly  in  their  practice;  and 

•  Using  developed  architecture  products  in  all  relevant  stages  of  development 
projects 

The  main  responsibilities  of  the  DMO  in  architecture  practice  include: 

•  To  produce  the  vendor  architecture  practice  guidance  in  accordance  with  the 
ADO's  architecture  practice,  in  order  to  ensure  vendors  follow  the  practice  of  the 
ADO; 

•  To  support  implementation  of  knowledge  acquisition  as  part  of  acquisition 
business; 

•  To  ensure  that  those  involved  in  the  processes  of  project  approval  and  budgeting 
make  best  use  of  architecture  to  reduce  costs  and  avoid  failures  in  IT  development; 
and 

•  To  assist  in  the  acquisition  of  the  enterprise  systems  architecture,  if  this  is  another 
agency's  responsibility. 

12.3  Defence  Information  Systems  Group  (DISG) 

DISG's  interests  in  architecture  focuses  mainly  on  certain  enterprise  architecture 
products,  such  as  technical  architecture  (or  framework).  Network  communications 
architecture.  Common  Operating  Environment  (COE)  and  various  standards. 
Therefore,  DISG  is  one  of  the  main  agencies  that  generates  important  supporting 
elements  for  the  architecture  practice  supporting  environment  (APSE)  of  the  ADO.  To 
make  its  products  widely  accessible  to  the  whole  defence  community,  they  should  be 
delivered  as  part  of  the  APSE. 

12.4  Australian  Defence  Force  (ADF) 

In  architecture  practice,  the  main  responsibilities  of  the  ADF  are  development  of  the 
operational  architecture  subset,  which  includes: 

•  The  development  of  operational  architectures  (see  the  definition  in  the  C4ISR  AF, 
which  is  mainly  suitable  for  operation  description  at  a  level  of  military  mission 
planning)  and  other  architecture  products  associated  as  either  references  or 
supporting  elements  for  all  levels  and  scenarios  of  military  operations.  Included 
here  are  such  things  as  Military  Response  Options  (MROs),  task  lists  and  other 
rule-based  references  used  to  support  campaign  and  mission  planning.  This  will 
lead  to  more  effective  generation,  management  and  reuse  of  organisational 
knowledge. 
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•  The  definition  and  standardisation  of  the  development  processes  for  operational 
architectures  for  important  areas  of  the  ADF,  such  as  HQAST  and  other  strategic 
and  operational  level  headquarters. 

•  Collaboration  with  other  agencies  (such  as  DSTO)  to  understand  the  ADF's  special 
requirements  in  architecture  practice,  for  example,  those  related  to  supporting 
military  campaigns,  and  also  specific  IT  development  capabilities  that  are  required, 
such  simulation  and  modelling. 


The  operational  areas  of  the  ADF  will  be  one  of  the  main  beneficiaries  of  the  defence 
wide  architecture  practice,  since  their  future  development  will  be  supported  through 
use  of  architecture-based  capabilities.  These  capabilities  should  be  designed  to  meet  the 
requirements  for  addressing  the  features  of  future  warfare,  such  as  network-centric 
warfare,  and  supporting  "sensor-to-shooter"  information-based  solution  optimisation. 
They  should  be  delivered  through  improved  solutions  for  the  generation,  management 
and  evolution  of  military  operations  knowledge. 

Using  architecture  for  the  description  of  military  operation  concepts  will  make  it 
possible  to  better  align  IT  development  with  business  change.  Operational  architecture 
development  is  a  new  area  for  both  military  and  IT  staff  and  requires  joint  efforts  to 
make  it  become  part  of  the  ADO  architecture  practice.  For  similar  reasons  to  those  for 
architecture  practice  overall,  adequate  high  level  planning  and  scheduling  for 
operational  architecture  development  is  necessary  in  order  to  ensure  consistency  in  use 
of  terminology  and  techniques  amongst  the  various  activities  that  may  generate 
operational  architectures  or  relevant  products  for  different  parts  of  the  ADF. 

Operational  architecture  development  for  the  ADF  is  not  about  development  of  a 
single  product.  It  should  indeed  involve  a  set  of  relevant  architecture  products,  which 
can  be  either  descriptive  or  supporting  products,  and  a  set  of  processes,  which  are 
designed  for  the  generation  and  use  of  operational  architectures  for  different  areas  of 
the  ADF. 

In  the  recommended  architecture  practice  model,  developing  an  operational 
architecture  for  a  new  system  or  a  specific  mission  is  seen  as  part  of  the  system 
architecture  construction  process.  The  development  of  various  supporting  elements  for 
operational  architecture  generation  is  not  included  in  the  model.  In  the  ADO'  APSE 
shown  in  Figure  9-1,  however,  we  expect  different  agencies  to  make  their  contributions 
to  relevant  areas  of  architecture  resources  that  includes  those  supporting  elements  for 
operational  architecture  development. 

To  the  authors'  somewhat  limited  understanding  to  date,  it  seems  necessary  to  further 
decompose  the  task  in  the  area  of  operational  architecture  development  into  sub-tasks. 
Operation  architectures /concepts  should  be  developed  differently  in  certain  different 
domains  (Land,  Air,  Maritime  or  Joint),  levels  (strategic,  operational  or  tactical)  and 
scenarios  (event-driven).  Coordination  among  these  sub-tasks  is  required  and  is  better 
addressed  using  architecture  practice  thinking. 

The  C4ISR  AF  was  introduced  by  the  US  DoD  to  guide  development  of  all  C4ISR 
architectures  including  operational  architectures.  The  ADF  needs  to  first  look  at 
whether  this  approach  is  suitable  for  the  ADF  and  whether  it  can  be  used  by  the  ADF 
after  appropriate  modification. 
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If  it  is  shown  that  the  C4ISR  AF  (Version  3  is  being  developed)  is  not  suitable  for  the 
ADF,  then  a  decision  should  be  made  to  develop  either  a  unified  operational 
architecture  development  approach  for  the  whole  ADF,  or  selected  approaches  for 
different  parts. 

Through  the  ADO's  APSE,  the  integrated  architecture  capability  for  the  C4ISR  domain 
should  include: 

•  Architecture  products  both  descriptive  and  supporting  used  as  knowledge 
resources  to  develop  operational  architectures  for  all  areas  and  levels  of  the  ADF; 
and 

•  Architecture-based  functions/ services  for  both  generic  purposes  (such  as  creation, 
navigation,  publication,  visualisation  of  architecture)  and  specific  purposes  (such  as 
architecture-based  planning,  simulation,  and  performance  evaluation  of  SOS). 

12.5  DSTO 

Architecture  practice  is  an  emerging  discipline  and  involves  many  challenges  in 
research  and  development.  This  discipline  is  related  to  many  R&D  areas  of  DSTO, 
including  information  architectures,  systems  engineering,  software  engineering, 
systems  simulation  and  assessment,  systems  of  systems,  military  operations  studies, 
information  operations  and  various  information-based  capability  developments  where 
architecture  products  are  either  generated  or  used. 

Along  with  the  cultural  change  of  the  ADO  through  use  of  architecture  to  support  its 
future  development,  it  is  also  appropriate  for  DSTO  to  consider  how  its  research 
culture  and  capability  can  be  improved  based  on  architecture  in  order  to  provide  better 
advice  and  services  to  the  ADO.  Opportunities  for  improvement  lie  in  the  following 
aspects: 

•  Consideration  of  architecture  as  a  capability  that  can  be  delivered  to  clients  through 
well-developed  architecture  practice; 

•  To  use  architecture  practice  as  a  basis  for  integration  of  relevant  DSTO  R&D 
outcomes,  in  particular  through  making  contributions  to  the  development  of  either 
architecture  products/resources  or  architecture-based  functions /services  in 
various  areas  for  the  ADO's  APSE; 

•  To  actively  participate  in  development  of  the  architecture  practice  supporting 
environment  for  the  ADO,  which  will  provide  DSTO  with  opportunities  to  identify 
what  is  needed  by  the  ADO  in  its  future  development;  and 

•  To  better  use  its  leading  position  in  architecture  practice  research  for  establishment 
of  broad  contacts  and  collaboration  with  R&D  teams  across  the  organisation  and 
around  the  world. 

12.6  Support  from  industry 

Industry's  capabilities  in  architecture  have  been  developed  over  the  last  three  decades 
supporting  many  individual  activities  in  IT  practice.  These  capabilities  are  mainly 
classified  in  four  areas  according  to  their  different  natures. 
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•  System  architecture  solutions-e.g.  3-tiers,  Client /Server,  CORBA-based,  Web- 
based,  Component-based,  Middleware,  Messaging,  ... 

•  Architectural  methodologies/  enterprise  architecture  frameworks 

•  Software  system  development  methodologies 

•  Tools /environments 

These  capabilities  are  available  through  two  different  types  of  providers: 

•  Consulting  Services  providers,  including: 

-  Solution  providers  -  e.g.  OOPL  or  CSC 

-  Coaching  services  —  e.g.  Meta  Group  /  Gartner  Group 

-  Concept  studies  (such  as  IT  planning  and  technical  options) 

•  Tool  suppliers,  including 

-  CASE  /architecture  Tools  -  e.g.  Rationale  Rose/  System  Architect/  Cool 
Family/  Ptech 

-  Repository  tools/Web-based  publishing. 

One  of  challenges  facing  the  ADO  is  how  to  properly  use  these  industry  capabilities  in 
an  integrated  manner  and  integrate  them  into  the  ADO's  architecture  practice  and 
APSE. 

12.7  Architecture  practice  working  groups 

Architecture  practice  involves  considerable  strategic  decision  making  at  an  enterprise 
level. 

Decisions  on  selection  and  development  of  architecture  frameworks  and  enterprise 
supporting  elements  (such  as  a  technical  architecture  framework)  should  be  made  by 
an  architecture  practice  working  group. 

This  working  group  needs  to  include  representatives  across  the  full  spectrum  of  the 
defence  organisation,  so  that  the  decisions  made  will  be  respected  and  effectively 
implemented.  Without  such  broad  representation,  the  diverse  requirements  of 
disparate  parts  of  the  organisation  will  not  be  properly  addressed,  resulting  in 
inappropriate  decisions  that  do  not  meet  the  needs  of  the  organisation. 

This  group  will  have  to  play  the  key  role  in  the  following  areas: 

•  Developing  an  architecture  lexicon  for  the  ADO  s  architecture  practice, 

•  Making  formal  recommendations  for  the  main  decisions  of  the  ARB; 

•  Providing  support  to  the  CIA  and  DIE  Architecture  Office, 

•  Organising  the  development  of  the  APSE  and  documents  to  guide  architecture 
practice. 
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13.  What  are  the  returns,  risks  and  costs  for 
architecture  practice? 

Like  any  activity  in  business,  architecture  practice  can  generate  returns,  operate  with 
certain  costs  and  face  risks. 

The  most  important  return  generated  from  the  enterprise  architecture  practice  is 
improved  IT  development  capability  and  future  organisation  development  capability. 
There  are  of  course  many  other  direct  or  indirect  returns  that  have  been  discussed 
throughout  this  report. 

It  has  been  reported,  however,  that  some  research  indicates  that  only  20%  of  an 
enterprise  architecture  is  strategically  valuable,  which  means  the  remaining  80%  yields 
little  reward.  This  finding  shows  that: 

1)  enterprise-wide  architecture  practice  involves  a  lot  of  risks,  predominantly  in 
selection  of  architecture  frameworks  to  be  used  and  architecture  products,  and  in 
particular  those  in  the  category  of  Enterprise  Supporting  Elements;  and 

2)  wasting  funds  is  quite  possible  in  an  ill-planned  architecture  practice,  since  a  high 
level  of  complexity  in  architecture  practice  cannot  guarantee  a  high  level  of 
maturity  or  success  in  the  practice. 

One  of  the  main  purposes  of  the  Architecture  Practice  Study  is  to  help  the  organisation 
to  lift  the  rate  of  return  by  properly  defining  the  context  of  architecture  practice, 
targeting  better  objectives,  and  correctly  selecting  architecture  products  to  be 
developed. 
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14.  Recommendations 


•  The  ARB  should  develop  architecture  practice  concepts  for  the  whole  ADO  at  a 
level  above  individual  architecture  development,  and  give  greater  attention  to 
architecture  practice  management,  in  order  to  generate  long  term  benefits.  The 
concepts  should  embody  a  mature  understanding  of  architecture  and  lead  to  the 
development  of  a  well-coordinated  overall  architecture  approach  specifically  for 
the  ADO  architecture  practice.  This  practice  is  aimed  at  generating  an  integrated 
architecture  capability. 

•  Since  the  practice  is  focused  towards  generating  the  capability  supporting  future 
organisation  development,  a  formal  architecture  product  planning  process  should 
be  defined  in  which  future  architecture  development  proposals  must  be  reviewed 
and  approved.  To  optimise  architecture  production  and  maximise  the  value  of 
architecture,  a  consistent  architecture  value  evaluation  method  should  be 
introduced  to  make  sure  that  an  architecture  is  developed  in  the  right  context,  at 
the  right  time  and  through  an  appropriate  methodology. 

•  A  well-developed  Architecture  Practice  Supporting  Environment  (APSE)  should  be 
developed  to  deliver  architecture  capabilities  in  an  integrated  manner.  A  web- 
based  repository,  even  only  for  a  specific  area  like  systems  architecture,  operational 
architectures  or  network  communications  architecture,  can  be  a  starting  point  or  a 
prototype  of  such  an  environment  and  help  to  demonstrate  architecture 

capabilities. 

•  Enterprise  architecture  issues,  such  as  the  enterprise  technical  architecture  or  other 
enterprise  supporting  or  reference  elements,  are  not  independent  of  or  isolated 
from  the  organisation's  traditional  R&D  activities  in  IT.  In  order  to  achieve  better 
integration,  relevant  parties  need  to  ensure  that  outcomes  of  their  work  fit  well  into 
the  context  of  the  architecture  practice  and  can  be  broadly  beneficial  to  the 
community. 

•  Managing  individual  architecture  development  efforts  is  less  complex  than 
managing  architecture  practice  and  cannot  lead  to  a  complete  enterprise 
architecture  solution.  The  ARB's  main  interests  should  be  in  developing  an 
architecture  culture  for  the  ADO,  rather  than  just  simply  products. 

•  The  ARB  and  DIEAO  should  consider  reaching  management  solutions  for  the  ADO 
architecture  practice  as  important  and  necessary  outcomes  of  their  business.  They 
need  to  find  adequate  resources  to  develop  important  documents  to  guide  the 
selection  and  use  of  architecture  frameworks  and  to  formulate  the  evaluation 
process  of  architecture  development  proposals. 

•  It  is  important  for  the  ADO  to  define  an  effective  method  for  communicating 
architectures  in  its  architecture  practice,  which  allows  the  community  developing 
and  using  architectures  to  visualise  and  understand  architecture  products  in  a 
consistent  and  standard  manner.  This  would  include  an  architecture  lexicon  to 
standardise  use  of  terminology,  and  an  easily-understood  and  well-accepted 
notational  system  for  architecture  representation. 


50 


DSTO-CR-OI 52 


The  ADO  should  aim  to  achieve  the  following  short  term  goals: 

•  Reach  a  common  understanding  that  the  ADO  needs  to  not  only  produce 
architecture  products,  but  also  and  more  importantly  a  well-planned  architecture 
practice. 

•  Develop  methods  for  evaluation  of  architecture  development  proposals; 

•  Start  to  use  the  concept  of  architecture  product  management  for  improving 
generation,  management  and  reuse  of  architecture  knowledge; 

•  Define  key  architecture  components  at  the  enterprise  level  to  reach  a  workable 
enterprise  architecture  framework  as  a  basis  for  planning  and  coordination; 

•  Identify  the  main  enterprise  supporting  elements,  such  as  UJTL,  MRO  and 
(Enterprise)  Technical  Architecture,  and  Reference  Models  for  communications 
and  interoperability; 

•  Prepare  technically  and  organisationally  for  conducting  domain  engineering 
related  activities  and  developing  a  systems  architecture  repository; 

•  Establish  working  groups  for  development  of  the  operational  architecture  subset 
and  the  technical  architecture  subset  and  their  associated  process  guidelines;  and 

•  Define  interrelationship  and  connections  between  process  and  architecture 
frameworks  to  improve  useability  of  individual  methodologies. 


The  ADO  should  aim  to  achieve  the  following  long  term  goals: 

•  Develop  and  maintain  an  architecture  knowledge  repository  and  enable  its  use  in 
practice  as  much  as  possible; 

•  Choose  a  suitable  existing  approach  if  possible,  or  develop  new  architecture 
approaches  or  frameworks,  for  developing  various  architecture  products  in  future 
organisation  development; 

•  Develop  architecture  practice  as  part  of  the  ADO's  culture  in  its  knowledge 
management  and  future  organisation  development; 

•  Ensure  architecture  and  integration  issues  of  large  systems  and  projects  are 
examined  properly  during  the  planning  process; 

•  Develop  supporting  concepts/elements  and  tools/APSE  for  the  integrated 
architecture  business  cycle  illustrated  in  Figure  5-2,  through  using  effective 
architecture  product  management  and  well-coordinated  efforts;  and 

•  Use  architecture-based  approaches  and  capabilities  to  integrate  the  responsibilities 
and  interests  of  different  business  areas  across  the  organisation  in  order  to  improve 
the  IT  development  capability  as  whole. 
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15.  Conclusions 

This  framework  study  systematically  discusses  architecture  issues  in  the  context  of  the 
whole  Defence  Organisation,  and  in  particular  those  issues  relating  to  supporting  the 
evolutionary  development  of  C4ISR  systems.  In  doing  so  it  strives  to  illustrate  three 
critical  roles  of  architecture: 

•  A  picture  of  the  current  state; 

•  A  blueprint  or  vision  for  the  future;  and 

•  A  roadmap  as  guidance  on  how  to  get  there. 

Successful  and  full-scale  use  of  architecture  for  all  these  three  main  purposes  in  an 
integrated  manner  is  important  for  maturation  of  an  organisation  s  IT  development 
capability.  In  practice  though,  it  is  also  very  complicated  and  difficult  to  achieve  in  a 
systems  of  systems  development  context.  These  three  roles  cannot  be  played  by  any 
single  architecture  product  no  matter  how  comprehensive  it  is  claimed  to  be  by  its 
developers.  It  is  the  architecture  practice  that  can  provide  a  context  for  all  architecture- 
related  activities  to  be  planned,  conducted,  managed  and  coordinated  towards 
achieving  an  integrated  architecture-based  capability.  The  ADO  must  develop  its  own 
architecture  practice  to  optimise  its  architecture  production  and  maximise  the  value  of 
architecture. 

Defining  and  developing  proper  strategies  will  help  us  not  only  in  dealing  with 
complexity  in  architecture,  but  will  also  have  a  significant  impact  on  performance  and 
cultural  change  of  the  ADO's  IT  practice.  Although  developing  individual  architecture 
products  can  generate  certain  architecture-based  capabilities,  they  must  be  integrated 
in  order  to  satisfy  the  broad  needs  of  the  ADO  for  improvement  in  its  future 
development  capability.  What  is  required  by  the  ADO  for  DIE  development  is  an 
integrated  architecture-based  capability  that  is  designed  for  supporting  the 
improvement  of  IT  development  capability,  and  one  that  can  successfully  evolve  over 
time  and  eventually  become  part  of  the  organisation  culture.  That  is  a  matured 
architecture  culture  in  which  any  architecture  is  developed  in  a  well-defined  context,  at 
the  right  time,  through  the  use  of  an  appropriate  methodology,  and  is  one  that  can  be 
integrated  with  others  and  used  broadly  and  effectively. 
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architecture  practice,  and  responsibilities  of  relevant  parties  are  also  discussed  in  the  report  to  help  reach  a  shared 
understanding  of  the  practice  required  by  the  ADO.  The  report  aims  to  provide  a  basis  or  context  for  the  Architecture 
Review  Board  to  plan  and  organise  the  architecture  practice  and  to  produce  more  detailed  guidelines. 
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